[PATCH 2.6.12 1/1] docs: updated some code docs

From: Xose Vazquez Perez
Date: Tue Jul 26 2005 - 17:23:15 EST

Updated docs about how to write and submit patches/code.
diff -Nuar old/Documentation/CodingStyle new/Documentation/CodingStyle
--- old/Documentation/CodingStyle 2005-07-26 00:10:55.000000000 +0200
+++ new/Documentation/CodingStyle 2005-07-25 23:58:37.000000000 +0200
@@ -422,10 +422,13 @@
URL: http://cm.bell-labs.com/cm/cs/tpop/

GNU manuals - where in compliance with K&R and this text - for cpp, gcc,
-gcc internals and indent, all available from http://www.gnu.org
+gcc internals and indent, all available from http://www.gnu.org/manual/

WG14 is the international standardization working group for the programming
language C, URL: http://std.dkuug.dk/JTC1/SC22/WG14/

+Kernel CodingStyle by greg@xxxxxxxxx at OLS 2002:
Last updated on 16 February 2004 by a community effort on LKML.
diff -Nuar old/Documentation/SubmittingDrivers new/Documentation/SubmittingDrivers
--- old/Documentation/SubmittingDrivers 2005-07-26 00:11:01.000000000 +0200
+++ new/Documentation/SubmittingDrivers 2005-07-27 00:07:10.000000000 +0200
@@ -26,17 +26,17 @@

Linux 2.0:
- No new drivers are accepted for this kernel tree
+ No new drivers are accepted for this kernel tree.

Linux 2.2:
+ No new drivers are accepted for this kernel tree.
+Linux 2.4:
If the code area has a general maintainer then please submit it to
the maintainer listed in MAINTAINERS in the kernel file. If the
maintainer does not respond or you cannot find the appropriate
- maintainer then please contact Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
-Linux 2.4:
- The same rules apply as 2.2. The final contact point for Linux 2.4
- submissions is Marcelo Tosatti <marcelo.tosatti@xxxxxxxxxxxx>.
+ maintainer then please contact Marcelo Tosatti
+ <marcelo.tosatti@xxxxxxxxxxxx>.

Linux 2.6:
The same rules apply as 2.4 except that you should follow linux-kernel
@@ -51,6 +51,7 @@
of exclusively GPL licensing, and if you wish the driver
to be useful to other communities such as BSD you may well
wish to release under multiple licenses.
+ See accepted licenses at include/linux/module.h

Copyright: The copyright owner must agree to use of GPL.
It's best if the submitter and copyright owner
@@ -141,5 +142,13 @@

Linux USB project:
- http://sourceforge.net/projects/linux-usb/
+ http://linux-usb.sourceforge.net/
+How to NOT write kernel driver by arjanv@xxxxxxxxxx
+ http://people.redhat.com/arjanv/olspaper.pdf
+Kernel Janitor:
+ http://janitor.kernelnewbies.org/

+Last updated on 25 Jul 2005.
diff -Nuar old/Documentation/SubmittingPatches new/Documentation/SubmittingPatches
--- old/Documentation/SubmittingPatches 2005-07-26 00:11:01.000000000 +0200
+++ new/Documentation/SubmittingPatches 2005-07-27 00:03:56.000000000 +0200
@@ -35,7 +35,7 @@

To create a patch for a single file, it is often sufficient to do:

- SRCTREE= linux-2.4
+ SRCTREE= linux-2.6
MYFILE= drivers/net/mydriver.c

@@ -48,9 +48,9 @@
or unmodified kernel source tree, and generate a diff against your
own source tree. For example:

- MYSRC= /devel/linux-2.4
+ MYSRC= /devel/linux-2.6

- tar xvfz linux-2.4.0-test11.tar.gz
+ tar xvfz linux-2.6.0.tar.gz
mv linux linux-vanilla
wget http://www.moses.uklinux.net/patches/dontdiff
diff -uprN -X dontdiff linux-vanilla $MYSRC > /tmp/patch
@@ -77,7 +77,7 @@

Andrew Morton's patch scripts:

2) Describe your changes.

@@ -94,7 +94,7 @@

3) Separate your changes.

-Separate each logical change into its own patch.
+Separate each _logical changes_ 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
@@ -102,13 +102,17 @@
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.
+group those changes into a single patch. Thus single logical changes
+are 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.

+If you cannot condense your patch set into a smaller set of patches,
+then only post say 15 or so at a time and wait for review and integration.

4) Select e-mail destination.

@@ -121,6 +125,8 @@
linux-kernel@xxxxxxxxxxxxxxxx Most kernel developers monitor this
e-mail list, and can comment on your changes.

+Do not send more than 15 patches at once to the vger mailing lists!!!
Linus Torvalds is the final arbiter of all changes accepted into the
Linux kernel. His e-mail address is <torvalds@xxxxxxxx>. He gets
a lot of e-mail, so typically you should do your best to -avoid- sending
@@ -153,6 +159,8 @@

Unless you have a reason NOT to do so, CC linux-kernel@xxxxxxxxxxxxxxxx

+Do not send more than 15 patches at once to the vger mailing lists!!!
Other kernel developers besides Linus need to be aware of your change,
so that they may comment on it and offer code review and suggestions.
linux-kernel is the primary Linux kernel developer mailing list.
@@ -161,6 +169,9 @@
MAINTAINERS file for a mailing list that relates specifically to
your change.

+Majordomo lists of VGER.KERNEL.ORG at:
+ http://vger.kernel.org/vger-lists.html
Even if the maintainer did not respond in step #4, make sure to ALWAYS
copy the maintainer when you change their code.

@@ -378,3 +389,24 @@

+'The perfect patch' by akpm@xxxxxxxx:
+ http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
+'Linux kernel patch submission format' by jgarzik@xxxxxxxxx:
+ http://linux.yyz.us/patch-format.html
+'How to piss off a kernel subsystem maintainer' by greg@xxxxxxxxx:
+ http://www.kroah.com/log/2005/03/31/
+ http://www.kroah.com/log/2005/07/08/
+NO!!!! No more huge patch bombs to linux-kernel@xxxxxxxxxxxxxxx people!:
+Last updated on 25 Jul 2005.