diff options
authorRandy Dunlap <>2005-06-28 20:45:30 -0700
committerLinus Torvalds <>2005-06-28 21:20:37 -0700
commit84da7c0844f8ab7668559c61e4f0af416fc58cf6 (patch)
parent6623e6205e36c310367009f3b01f5cbe7cc0005d (diff)
[PATCH] Doc/Submitting: corrections, additions
Corrections to Documentation/Submitting{Drivers,Patches} - update LANANA info. - fix some typos - update 2.2 kernel maintainer info. - update 'dontdiff' info. - update URLs for patch scripts - add Trivial Patch Monkey URL - add more references for submitting patches Signed-off-by: Randy Dunlap <> Signed-off-by: Andrew Morton <> Signed-off-by: Linus Torvalds <>
2 files changed, 37 insertions, 21 deletions
diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers
index de3b252e717..c3cca924e94 100644
--- a/Documentation/SubmittingDrivers
+++ b/Documentation/SubmittingDrivers
@@ -13,13 +13,14 @@ Allocating Device Numbers
Major and minor numbers for block and character devices are allocated
-by the Linux assigned name and number authority (currently better
-known as H Peter Anvin). The site is This
+by the Linux assigned name and number authority (currently this is
+Torben Mathiasen). The site is This
also deals with allocating numbers for devices that are not going to
be submitted to the mainstream kernel.
+See Documentation/devices.txt for more information on this.
-If you don't use assigned numbers then when you device is submitted it will
-get given an assigned number even if that is different from values you may
+If you don't use assigned numbers then when your device is submitted it will
+be given an assigned number even if that is different from values you may
have shipped to customers before.
Who To Submit Drivers To
@@ -32,7 +33,8 @@ Linux 2.2:
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 <>
+ maintainer then please contact the 2.2 kernel maintainer:
+ Marc-Christian Petersen <>.
Linux 2.4:
The same rules apply as 2.2. The final contact point for Linux 2.4
@@ -48,7 +50,7 @@ What Criteria Determine Acceptance
Licensing: The code must be released to us under the
GNU General Public License. We don't insist on any kind
- of exclusively GPL licensing, and if you wish the driver
+ of exclusive 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.
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 4d1f41b84eb..6761a7b241a 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -35,7 +35,7 @@ not in any lower subdirectory.
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,17 +48,18 @@ 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
+ MYSRC= /devel/linux-2.6
- tar xvfz linux-2.4.0-test11.tar.gz
- mv linux linux-vanilla
- wget
- diff -uprN -X dontdiff linux-vanilla $MYSRC > /tmp/patch
- rm -f dontdiff
+ tar xvfz linux-2.6.12.tar.gz
+ mv linux-2.6.12 linux-2.6.12-vanilla
+ diff -uprN -X linux-2.6.12-vanilla/Documentation/dontdiff \
+ linux-2.6.12-vanilla $MYSRC > /tmp/patch
"dontdiff" is a list of files which are generated by the kernel during
the build process, and should be ignored in any diff(1)-generated
-patch. dontdiff is maintained by Tigran Aivazian <>
+patch. The "dontdiff" file is included in the kernel tree in
+2.6.12 and later. For earlier kernel versions, you can get it
+from <>.
Make sure your patch does not include any extra files which do not
belong in a patch submission. Make sure to review your patch -after-
@@ -66,18 +67,20 @@ generated it with diff(1), to ensure accuracy.
If your changes produce a lot of deltas, you may want to look into
splitting them into individual patches which modify things in
-logical stages, this will facilitate easier reviewing by other
+logical stages. This will facilitate easier reviewing by other
kernel developers, very important if you want your patch accepted.
-There are a number of scripts which can aid in this;
+There are a number of scripts which can aid in this:
Randy Dunlap's patch scripts:
Andrew Morton's patch scripts:
2) Describe your changes.
@@ -163,6 +166,8 @@ patches. Trivial patches must qualify for one of the following rules:
since people copy, as long as it's trivial)
Any fix by the author/maintainer of the file. (ie. patch monkey
in re-transmission mode)
+URL: <>
@@ -291,6 +296,17 @@ now, but you can do this to mark internal company procedures or just
point out some special detail about the sign-off.
+12) More references for submitting patches
+Andrew Morton, "The perfect patch" (tpp).
+ <>
+Jeff Garzik, "Linux kernel patch submission format."
+ <>
@@ -359,7 +375,5 @@ 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"
+be useful: "Make it as simple as you can, and no simpler."