Date: Thu, 16 Nov 2000 15:32:40 -0600
Message-Id: <200011162132.PAA01944@mandrakesoft.mandrakesoft.com>
From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: torvalds@transmeta.com, linux-kernel@vger.kernel.org
Subject: RFC: "SubmittingPatches" text
Sender: linux-kernel-owner@vger.kernel.org

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 torvalds@transmeta.com.

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,
linux-kernel@vger.kernel.org, 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,
linux-kernel@vger.kernel.org.  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 linux-kernel@vger.kernel.org,
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"


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/