I'd like to put the following document into the kernel tree as
linux/Documentation/SubmittingPatches, and would like to get comments
on it.
I've likely left out a lot in Section 2... additions welcome.
I don't want to get too domain-specific in section 2, but I would
like to cover as many "unwritten general rules" as possible.
Jeff
How to Get Your Change Into the Linux Kernel
or
The Unofficial Linus HOWTO
For a person or company who wishes to submit a change to the Linux
kernel, the process can sometimes be daunting if you're not familiar
with "the system." This text is a collection of suggestions which
can greatly increase the chances of your change being accepted.
--------------------------------------------
SECTION 1 - CREATING AND SENDING YOUR CHANGE
--------------------------------------------
1) "diff -u"
------------
Use "diff -u" or "diff -urN" to create patches.
All changes to the Linux kernel occur in the form of patches, as
generated by diff(1). When creating your patch, make sure to create it
in "unified diff" format, as supplied by the '-u' argument to diff(1).
Patches should be based in the root kernel source directory, not in
any lower subdirectory.
To create a patch for a single file, it is often sufficient to do:
SRCTREE=/usr/src/linux
MYFILE=drivers/net/mydriver.c
cd $SRCTREE
cp $MYFILE $MYFILE.orig
vi $MYFILE # make your change
diff -u $MYFILE.orig $MYFILE > /tmp/patch
To create a patch for multiple files, you should unpack a "vanilla",
or unmodified kernel source tree, and generate a diff against your
own source tree. For example:
MYSRC=/devel/linux-2.4
tar xvfz linux-2.4.0-test11.tar.gz
mv linux linux-vanilla
diff -urN linux-vanilla $MYSRC > /tmp/patch
2) Describe your changes.
Describe the technical detail of the change(s) your patch includes.
Be as specific as possible. The WORST descriptions possible include
things like "update driver X", "bug fix for driver X", or "this patch
includes updates for subsystem X. Please apply."
If your description starts to get long, that's a sign that you probably
need to split up your patch. See #3, next.
3) Separate your changes.
Separate each logical change into its own patch.
For example, if your changes include both bug fixes and performance
enhancements for a single driver, separate those changes into two
or more patches. If your changes include an API update, and a new
driver which uses that new API, separate those into two patches.
On the other hand, if you make a single change to numerous files,
group those changes into a single patch. Thus a single logical change
is contained within a single patch.
If one patch depends on another patch in order for a change to be
complete, that is OK. Simply note "this patch depends on patch X"
in your patch description.
4) Select e-mail destination.
The arbiter of all Linux kernel changes is Linus Torvalds. His e-mail
address is [email protected].
He gets a lot of e-mail. I mean a LOT. So you want to do your best
to avoid sending him e-mail. :)
Before sending your change to Linus, look through the MAINTAINERS
file and the source code, and determine if your change applies to
a specific subsystem of the kernel, with an assigned maintainer.
If so, e-mail that person instead.
If no maintainer is listed, or the maintainer does not respond, send
your patch to the primary Linux kernel developer's mailing list,
[email protected], in addition to Linus. Most kernel
developers monitor this e-mail list, and can comment on your changes.
5) Select your CC (e-mail carbon copy) list.
Other kernel developers besides Linus need to be aware of your change,
so they want comment on it and offer code review and suggestions.
When e-mailing your change, typically the change is copied
to the primary Linux kernel developer's mailing list,
[email protected]. Other mailing lists are available
for specific subsystems, such as USB, framebuffer devices, the VFS,
the SCSI subsystem, etc.
Even if the maintainer did not respond in step #4, make sure to ALWAYS
copy the maintainer when you change their code.
If your change is in any way large (conceptually, not byte size)
or controversial, you should copy [email protected],
so that the change can be discussed.
6) No MIME, no links, no compression, no attachments. Just plain text.
Linus and other kernel developers need to be able to read and
comment on the changes you are submitting. It is important for a
kernel developer to be able to "quote" your changes, using standard
e-mail tools, so that they may comment on specific portions of your code.
For this reason, all patches should be submitting e-mail "inline".
Do not attach the patch as a MIME attachment, compressed or not.
Many popular e-mail applications will not always transmit a MIME
attachment as plain text, making it impossible to comment on your
code. A MIME attachment also takes Linus a bit more time to process,
decreasing the likelihood of your MIME-attached change being accepted.
7) E-mail size.
When sending patches to Linus, always follow step #6.
Large changes are not appropriate for mailing lists, and some
maintainers. If your patch, uncompressed, exceeds 40Kb in size,
it is preferred that you store your patch on an Internet-accessible
server, and provide instead a URL (link) pointing to your patch.
8) Name your kernel version.
It is important to note, either in the subject line or in the patch
description, the kernel version to which this patch applies.
9) Don't get discouraged. Re-submit.
After you have submitted your change, be patient and wait. If Linus
likes your change and applies it, it will appear in the next version
of the kernel that he releases.
However, if your change doesn't appear in the next version of the
kernel, there could be any number of reasons. It's YOUR job to
narrow down those reasons, correct what was wrong, and submit your
updated change.
It is quite common for Linus to "drop" your patch without comment.
That's the nature of the system. If he drops your patch, it could be
due to
* A style issue (see section 2),
* An e-mail formatting issue (re-read this section)
* A technical problem with your change
* He gets tons of e-mail, and yours got lost in the shuffle
* You are being annoying (See Figure 1)
When in doubt,
-----------------------------------
SECTION 2 - HINTS, TIPS, AND TRICKS
-----------------------------------
This section lists many of the common "rules" associated with code
submitted to the kernel. There are always exceptions... but you must
have a really good reason for doing so. You could probably call this
section Linus Computer Science 101.
1) Read Documentation/CodingStyle
Nuff said. If your code deviates too much from this, it is likely
to be rejected without further review, and without comment.
2) #ifdefs are ugly
Code cluttered with ifdefs is difficult to read and maintain. Don't do
it. Instead, put your ifdefs in a header, and conditionally define
'static inline' functions, or macros, which are used in the code.
Let the compiler optimize away the "no-op" case.
Simple example, of poor code:
dev = init_etherdev (NULL, 0);
if (!dev)
return -ENODEV;
#ifdef CONFIG_NET_FUNKINESS
init_funky_net(dev);
#endif
Cleaned-up example:
(in header)
#ifndef CONFIG_NET_FUNKINESS
static inline void init_funky_net (struct net_device *d) {}
#endif
(in the code itself)
dev = init_etherdev (NULL, 0);
if (!dev)
return -ENODEV;
init_funky_net(dev);
3) 'static inline' is better than a macro
Static inline functions are greatly preferred over macros.
They provide type safety, have no length limitations, no formatting
limitations, and under gcc they are as cheap as macros.
Macros should only be used for cases where a static inline is clearly
suboptimal [there a few, isolated cases of this in fast paths],
or where it is impossible to use a static inline function [such as
string-izing].
'static inline' is preferred over 'static __inline__', 'extern inline',
and 'extern __inline__'.
4) Don't over-design.
Don't try to anticipate nebulous future cases which may or may not
be useful: "Make it as simple as you can, and no simpler"
> The Unofficial Linus HOWTO
'Care And Operation Of Your Linus Torvalds'
> mv linux linux-vanilla
> diff -urN linux-vanilla $MYSRC > /tmp/patch
Include Tigrans recommended exclude list and info
> code. A MIME attachment also takes Linus a bit more time to process,
> decreasing the likelihood of your MIME-attached change being accepted.
+ If your mailer is mangling patches then someone may ask you to resend them
+ using MIME.
Maybe also note that maintainers of given modules are much more likely to
give feedback than Linus, also the [PATCH]: convention
Alan
On Thu, 16 Nov 2000, Alan Cox wrote:
> > The Unofficial Linus HOWTO
>
> 'Care And Operation Of Your Linus Torvalds'
>
>
> > mv linux linux-vanilla
> > diff -urN linux-vanilla $MYSRC > /tmp/patch
>
> Include Tigrans recommended exclude list and info
Alan Cox is very concise. I shall interpret :)
He refers to the dontdiff file I currently maintain on:
http://www.moses.uklinux.net/patches/dontdiff
and the command line to make the patch would become:
diff -urN -X dontdiif linux $MYSRC > /tmp/mysrc.patch
Regards,
Tigran
Alan and Tigran's comments folded in and Wiki-fied ;)
http://kernelbook.sourceforge.net:80/wiki/?PreparingPatches
This is not meant to replace the Documentation/... guide, only to
provide means for future public contributions. Consider it a
tentative preview, not a formal publication, and change it as
you wish.
--
Gary Lawrence Murphy <[email protected]>: office voice/fax: 01 519 4222723
T(!c)Inc Business Innovation through Open Source http://www.teledyn.com
M:I-3 - Documenting the Linux kernel: http://kernelbook.sourceforge.net
"You don't play what you know; you play what you hear." --- Miles Davis
[Jeff Garzik]
> MYSRC=/devel/linux-2.4
>
> tar xvfz linux-2.4.0-test11.tar.gz
> mv linux linux-vanilla
> diff -urN linux-vanilla $MYSRC > /tmp/patch
You should use an example where $MYSRC is a single directory level
(rather than absolute path) so people can use 'patch -NEp1' rather than
having to count levels.
> 4) Select e-mail destination.
>
> The arbiter of all Linux kernel changes is Linus Torvalds. His e-mail
> address is [email protected].
You should talk about peer review. For nontrivial changes you should
basically never send them straight to Linus (unless you yourself are a
maintainer) -- first offer them up on mailing lists and get feedback.
Tell people to look in MAINTAINERS for the appropriate list, with
possible CC to linux-kernel.
> Before sending your change to Linus, look through the MAINTAINERS
> file and the source code, and determine if your change applies to
> a specific subsystem of the kernel, with an assigned maintainer.
> If so, e-mail that person instead.
Note that for simple typo corrections and such, Linus should probably
get a CC even if you are mailing another maintainer. I.e. one less
level of indirection for the trivial stuff.
> When e-mailing your change, typically the change is copied
> to the primary Linux kernel developer's mailing list,
> [email protected]. Other mailing lists are available
> for specific subsystems, such as USB, framebuffer devices, the VFS,
> the SCSI subsystem, etc.
Again, either here or above, you should mention that one can usually
find a relevent list in MAINTAINERS.
> 9) Don't get discouraged. Re-submit.
>
> After you have submitted your change, be patient and wait. If Linus
> likes your change and applies it, it will appear in the next version
> of the kernel that he releases.
10) Make sure your patch is up to date, and keep it that way. Until it
is accepted into the main tree, you need to make sure it always applies
without errors to the most recent kernels, including pre-patches.
(Line offsets are OK; the 'patch' command has no trouble with these.)
This can be a lot of work when the kernel is in a volatile state, but
it is good if you can make sure that you are no more than 2 or 3 days
behind "the latest". Note that if you followed 3) and your patch is
small and self-contained, in many cases you won't need to change it for
weeks.
11) If Linus or others tell you a change is stupid, chances are they
have a point. If you must argue your case, use technical reasoning,
not marketing. Arguments like "but XXX OS does it this way" carry very
little weight -- instead, give us independent reasons why "this way" is
good. Linux is not Solaris, NT, FreeBSD, or BeOS, and we like it that
way. Arguments like "but XXX is required for better YYY compliance"
carry more weight, but you may still need to justify why YYY compliance
is important, and why it can't be achieved another way. Arguments like
"but we have BIGNUM customers / software vendors / gov't agencies who
will deploy/support Linux as soon as it has feature XXX" are completely
worthless, unless you can show that those customers, vendors or
agencies have solid technical reasons to want feature XXX (as opposed
to "but XXX OS does it this way and we don't want to port our software"
reasons).
Peter
On Thu, 16 Nov 2000, Jeff Garzik wrote:
> To create a patch for a single file, it is often sufficient to do:
>
> SRCTREE=/usr/src/linux
> MYFILE=drivers/net/mydriver.c
>
> cd $SRCTREE
> cp $MYFILE $MYFILE.orig
> vi $MYFILE # make your change
> diff -u $MYFILE.orig $MYFILE > /tmp/patch
One question comes to my mind: Are patches supposed to be applied with
patch -p0 or patch -p1?
AFAIU, the preferred way is -p1, but the above example would need -p0, if
I'm not mistaken. So that'ld make it harder than necessary to collect
patches and then apply the whole set, which seems to be Linus' preferred
way.
--Kai
On Fri, Nov 17, 2000 at 09:30:13AM +0100, Kai Germaschewski wrote:
> One question comes to my mind: Are patches supposed to be applied with
> patch -p0 or patch -p1?
Suppose the kernel tree is in /kernpath, starting with /kernpath/linux.
Linus' patches can be applied by (cd /kernpath; patch -p0 -s < patch)
while Alan's patches only work if you do
(cd /kernpath/linux; patch -p1 -s < ../patch)
Alan Cox wrote:
> Maybe also note that maintainers of given modules are much more likely to
> give feedback than Linus, also the [PATCH]: convention
Question:
Should a submitter CC Linus or linux-kernel on the patch before having
gotten approval from a maintainer?
I'd say DO CC Linux-kernel, don't CC Linus.
Otherwise Linus may get a patch that he doesn't know if it violates
the essential ideas behind some vague driver. And the message with it
could say: "As suggested by <driver-author>".
If Linux-kernel and the driver-author don't have any objections to the
patch, send it to Linus and the driver author, keeping Linux-kernel
out of the loop, this time with a note:
"Linus: Reviewed by <driver-author> and Linux-kernel,
please apply".
Note that Linus will not have read the previous discussion, so some of
the ideas of the patch may have to be repeated....
This is the way I'd like things to work. Feel free to disagree, and
try to convince me why it's wrong....
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* Common sense is the collection of *
****** prejudices acquired by age eighteen. -- Albert Einstein ********
Andries Brouwer wrote:
> On Fri, Nov 17, 2000 at 09:30:13AM +0100, Kai Germaschewski wrote:
>
> > One question comes to my mind: Are patches supposed to be applied with
> > patch -p0 or patch -p1?
>
> Suppose the kernel tree is in /kernpath, starting with /kernpath/linux.
> Linus' patches can be applied by (cd /kernpath; patch -p0 -s < patch)
^^^^ ALSO
> while Alan's patches only work if you do
> (cd /kernpath/linux; patch -p1 -s < ../patch)
For uniformity, I would recommend that everyone generates patches that
are "Linus-style", but that when applying, you treat them as "Alan-style".
Less chances for surprises.
Roger.
--
** [email protected] ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* Common sense is the collection of *
****** prejudices acquired by age eighteen. -- Albert Einstein ********
Rogier Wolff wrote:
> I'd say DO CC Linux-kernel, don't CC Linus.
Agreed. Posting to linux-kernel (as opposed to only the maintainer and/or
Linus) serves the following purposes:
- For patches introducing new features or changing existing ones,
this exposes them to public review. (Every once in a while, even
seemingly trivial and harmless patches are found to be wrong.)
- For patches fixing problems, this confirms the existence of the
problem to people who are dimly aware of it, it provides a possible
solution to those looking for one, and it tells those who are trying
to fix it that somebody else is already working on it.
Concerning Cc to Linus, well, I'd be surprised if he's dying to get
more mail of the "FYI" type ;-)
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, ICA, EPFL, CH [email protected] /
/_IN_N_032__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/