Newer
Older
List of maintainers and how to submit kernel changes
====================================================
Please try to follow the guidelines below. This will make things
easier on the maintainers. Not all of these guidelines matter for every
trivial patch so apply some common sense.
Tips for patch submitters
-------------------------
1. Always *test* your changes, however small, on at least 4 or
5 people, preferably many more.
2. Try to release a few ALPHA test versions to the net. Announce
them onto the kernel channel and await results. This is especially
important for device drivers, because often that's the only way
you will find things like the fact version 3 firmware needs
a magic fix you didn't know about, or some clown changed the
chips on a board and not its name. (Don't laugh! Look at the
SMC etherpower for that.)
3. Make sure your changes compile correctly in multiple
configurations. In particular check that changes work both as a
module and built into the kernel.
4. When you are happy with a change make it generally available for
testing and await feedback.
5. Make a patch available to the relevant maintainer in the list. Use
``diff -u`` to make the patch easy to merge. Be prepared to get your
changes sent back with seemingly silly requests about formatting
and variable names. These aren't as silly as they seem. One
job the maintainers (and especially Linus) do is to keep things
looking the same. Sometimes this means that the clever hack in
your driver to get around a problem actually needs to become a
generalized kernel feature ready for next time.
PLEASE check your patch with the automated style checker
(scripts/checkpatch.pl) to catch trivial style violations.
See Documentation/process/coding-style.rst for guidance here.
PLEASE CC: the maintainers and mailing lists that are generated
by ``scripts/get_maintainer.pl.`` The results returned by the
script will be best if you have git installed and are making
your changes in a branch derived from Linus' latest git tree.
See Documentation/process/submitting-patches.rst for details.
PLEASE try to include any credit lines you want added with the
patch. It avoids people being missed off by mistake and makes
it easier to know who wants adding and who doesn't.
PLEASE document known bugs. If it doesn't work for everything
or does something very odd once a month document it.
PLEASE remember that submissions must be made under the terms
of the Linux Foundation certificate of contribution and should
include a Signed-off-by: line. The current version of this
"Developer's Certificate of Origin" (DCO) is listed in the file
Documentation/process/submitting-patches.rst.
6. Make sure you have the right to send any changes you make. If you
do changes at work you may find your employer owns the patch
not you.
7. When sending security related changes or reports to a maintainer
please Cc: security@kernel.org, especially if the maintainer
Willy Tarreau
committed
does not respond. Please keep in mind that the security team is
a small set of people who can be efficient only when working on
verified bugs. Please only Cc: this list when you have identified
that the bug would present a short-term risk to other users if it
were publicly disclosed. For example, reports of address leaks do
not represent an immediate threat and are better handled publicly,
and ideally, should come with a patch proposal. Please do not send
automated reports to this list either. Such bugs will be handled
better and faster in the usual public places. See
Documentation/admin-guide/security-bugs.rst for details.
8. Happy hacking.
Descriptions of section entries and preferred order
---------------------------------------------------
M: *Mail* patches to: FullName <address@domain>
R: Designated *Reviewer*: FullName <address@domain>
These reviewers should be CCed on patches.
L: *Mailing list* that is relevant to this area
S: *Status*, one of the following:
Supported: Someone is actually paid to look after this.
Maintained: Someone actually looks after it.
Odd Fixes: It has a maintainer but they don't have time to do
much other than throw the odd patch in. See below..
Orphan: No current maintainer [but maybe you could take the
role as you write your new code].
Obsolete: Old code. Something tagged obsolete generally means
it has been replaced by a better system and you
should be using that.
W: *Web-page* with status/info
Q: *Patchwork* web based patch tracking system site
B: URI for where to file *bugs*. A web-page with detailed bug
filing info, a direct bug tracker link, or a mailto: URI.
C: URI for *chat* protocol, server and channel where developers
usually hang out, for example irc://server/channel.
P: Subsystem Profile document for more details submitting
patches to the given subsystem. This is either an in-tree file,
or a URI. See Documentation/maintainer/maintainer-entry-profile.rst
for details.
T: *SCM* tree type and location.
Type is one of: git, hg, quilt, stgit, topgit
F: *Files* and directories wildcard patterns.
A trailing slash includes all files and subdirectory files.
F: drivers/net/ all files in and below drivers/net
F: drivers/net/* all files in drivers/net, but not below
F: */net/* all files in "any top level directory"/net
One pattern per line. Multiple F: lines acceptable.
X: *Excluded* files and directories that are NOT maintained, same
rules as F:. Files exclusions are tested before file matches.
Can be useful for excluding a specific subdirectory, for instance:
F: net/
X: net/ipv6/
matches all files in and below net excluding net/ipv6/
N: Files and directories *Regex* patterns.
N: [^a-z]tegra all files whose path contains tegra
(not including files like integrator)
One pattern per line. Multiple N: lines acceptable.
scripts/get_maintainer.pl has different behavior for files that
match F: pattern and matches of N: patterns. By default,
get_maintainer will not look at git log history when an F: pattern
match occurs. When an N: match occurs, git log history is used
to also notify the people that have git commit signatures.
K: *Content regex* (perl extended) pattern match in a patch or file.
For instance:
matches patches or files that contain "of_get_profile"
matches patches or files that contain one or more of the words
printk, pr_info or pr_err
One regex pattern per line. Multiple K: lines acceptable.
Maintainers List
----------------
.. note:: When reading this list, please look for the most precise areas
first. When adding to this list, please keep the entries in
alphabetical order.
M: Steffen Klassert <klassert@kernel.org>
F: Documentation/networking/device_drivers/ethernet/3com/vortex.rst
F: drivers/net/ethernet/3com/3c59x.c
M: David Dillow <dave@thedillows.org>
L: netdev@vger.kernel.org
F: drivers/net/ethernet/3com/typhoon*
3WARE SAS/SATA-RAID SCSI DRIVERS (3W-XXXX, 3W-9XXX, 3W-SAS)
M: Adam Radford <aradford@gmail.com>
M: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
6LOWPAN GENERIC (BTLE/IEEE 802.15.4)
M: Alexander Aring <alex.aring@gmail.com>
M: Jukka Rissanen <jukka.rissanen@linux.intel.com>
L: linux-bluetooth@vger.kernel.org
F: Documentation/networking/6lowpan.rst
F: include/net/6lowpan.h
F: net/6lowpan/
M: Andreas Koensgen <ajk@comnets.uni-bremen.de>
802.11 (including CFG80211/NL80211)
M: Johannes Berg <johannes@sipsolutions.net>
L: linux-wireless@vger.kernel.org
W: https://wireless.wiki.kernel.org/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git
F: Documentation/driver-api/80211/cfg80211.rst
F: Documentation/networking/regulatory.rst
F: include/linux/ieee80211.h
F: include/net/cfg80211.h
F: include/net/ieee80211_radiotap.h
F: include/net/iw_handler.h
Loading
Loading full blame...