Loading CREDITS +14 −12 Original line number Diff line number Diff line Loading @@ -2211,6 +2211,15 @@ D: OV511 driver S: (address available on request) S: USA N: Ian McDonald E: iam4@cs.waikato.ac.nz E: imcdnzl@gmail.com W: http://wand.net.nz/~iam4 W: http://imcdnzl.blogspot.com D: DCCP, CCID3 S: Hamilton S: New Zealand N: Patrick McHardy E: kaber@trash.net P: 1024D/12155E80 B128 7DE6 FF0A C2B2 48BE AB4C C9D4 964E 1215 5E80 Loading Loading @@ -2246,19 +2255,12 @@ S: D-90453 Nuernberg S: Germany N: Arnaldo Carvalho de Melo E: acme@conectiva.com.br E: acme@kernel.org E: acme@gnu.org W: http://bazar2.conectiva.com.br/~acme W: http://advogato.org/person/acme E: acme@mandriva.com E: acme@ghostprotocols.net W: http://oops.ghostprotocols.net:81/blog/ P: 1024D/9224DF01 D5DF E3BB E3C8 BCBB F8AD 841A B6AB 4681 9224 DF01 D: wanrouter hacking D: misc Makefile, Config.in, drivers and network stacks fixes D: IPX & LLC network stacks maintainer D: Cyclom 2X synchronous card driver D: wl3501 PCMCIA wireless card driver D: i18n for minicom, net-tools, util-linux, fetchmail, etc S: Conectiva S.A. D: IPX, LLC, DCCP, cyc2x, wl3501_cs, net/ hacks S: Mandriva S: R. Tocantins, 89 - Cristo Rei S: 80050-430 - Curitiba - Paran S: Brazil Loading Documentation/Changes +10 −0 Original line number Diff line number Diff line Loading @@ -237,6 +237,12 @@ udev udev is a userspace application for populating /dev dynamically with only entries for devices actually present. udev replaces devfs. FUSE ---- Needs libfuse 2.4.0 or later. Absolute minimum is 2.3.0 but mount options 'direct_io' and 'kernel_cache' won't work. Networking ========== Loading Loading @@ -390,6 +396,10 @@ udev ---- o <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html> FUSE ---- o <http://sourceforge.net/projects/fuse> Networking ********** Loading Documentation/CodingStyle +20 −1 Original line number Diff line number Diff line Loading @@ -410,7 +410,26 @@ Kernel messages do not have to be terminated with a period. Printing numbers in parentheses (%d) adds no value and should be avoided. Chapter 13: References Chapter 13: Allocating memory The kernel provides the following general purpose memory allocators: kmalloc(), kzalloc(), kcalloc(), and vmalloc(). Please refer to the API documentation for further information about them. The preferred form for passing a size of a struct is the following: p = kmalloc(sizeof(*p), ...); The alternative form where struct name is spelled out hurts readability and introduces an opportunity for a bug when the pointer variable type is changed but the corresponding sizeof that is passed to a memory allocator is not. Casting the return value which is a void pointer is redundant. The conversion from void pointer to any other pointer type is guaranteed by the C programming language. Chapter 14: References The C Programming Language, Second Edition by Brian W. Kernighan and Dennis M. Ritchie. Loading Documentation/DocBook/kernel-hacking.tmpl +1 −1 Original line number Diff line number Diff line Loading @@ -1105,7 +1105,7 @@ static struct block_device_operations opt_fops = { </listitem> <listitem> <para> Function names as strings (__func__). Function names as strings (__FUNCTION__). </para> </listitem> <listitem> Loading Documentation/SubmittingPatches +85 −1 Original line number Diff line number Diff line Loading @@ -301,8 +301,84 @@ now, but you can do this to mark internal company procedures or just point out some special detail about the sign-off. 12) The canonical patch format 12) More references for submitting patches The canonical patch subject line is: Subject: [PATCH 001/123] subsystem: summary phrase The canonical patch message body contains the following: - A "from" line specifying the patch author. - An empty line. - The body of the explanation, which will be copied to the permanent changelog to describe this patch. - The "Signed-off-by:" lines, described above, which will also go in the changelog. - A marker line containing simply "---". - Any additional comments not suitable for the changelog. - The actual patch (diff output). The Subject line format makes it very easy to sort the emails alphabetically by subject line - pretty much any email reader will support that - since because the sequence number is zero-padded, the numerical and alphabetic sort is the same. The "subsystem" in the email's Subject should identify which area or subsystem of the kernel is being patched. The "summary phrase" in the email's Subject should concisely describe the patch which that email contains. The "summary phrase" should not be a filename. Do not use the same "summary phrase" for every patch in a whole patch series. Bear in mind that the "summary phrase" of your email becomes a globally-unique identifier for that patch. It propagates all the way into the git changelog. The "summary phrase" may later be used in developer discussions which refer to the patch. People will want to google for the "summary phrase" to read discussion regarding that patch. A couple of example Subjects: Subject: [patch 2/5] ext2: improve scalability of bitmap searching Subject: [PATCHv2 001/207] x86: fix eflags tracking The "from" line must be the very first line in the message body, and has the form: From: Original Author <author@example.com> The "from" line specifies who will be credited as the author of the patch in the permanent changelog. If the "from" line is missing, then the "From:" line from the email header will be used to determine the patch author in the changelog. The explanation body will be committed to the permanent source changelog, so should make sense to a competent reader who has long since forgotten the immediate details of the discussion that might have led to this patch. The "---" marker line serves the essential purpose of marking for patch handling tools where the changelog message ends. One good use for the additional comments after the "---" marker is for a diffstat, to show what files have changed, and the number of inserted and deleted lines per file. A diffstat is especially useful on bigger patches. Other comments relevant only to the moment or the maintainer, not suitable for the permanent changelog, should also go here. See more details on the proper patch format in the following references. 13) More references for submitting patches Andrew Morton, "The perfect patch" (tpp). <http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt> Loading @@ -310,6 +386,14 @@ Andrew Morton, "The perfect patch" (tpp). Jeff Garzik, "Linux kernel patch submission format." <http://linux.yyz.us/patch-format.html> Greg KH, "How to piss off a kernel subsystem maintainer" <http://www.kroah.com/log/2005/03/31/> Kernel Documentation/CodingStyle <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle> Linus Torvald's mail on the canonical patch format: <http://lkml.org/lkml/2005/4/7/183> ----------------------------------- Loading Loading
CREDITS +14 −12 Original line number Diff line number Diff line Loading @@ -2211,6 +2211,15 @@ D: OV511 driver S: (address available on request) S: USA N: Ian McDonald E: iam4@cs.waikato.ac.nz E: imcdnzl@gmail.com W: http://wand.net.nz/~iam4 W: http://imcdnzl.blogspot.com D: DCCP, CCID3 S: Hamilton S: New Zealand N: Patrick McHardy E: kaber@trash.net P: 1024D/12155E80 B128 7DE6 FF0A C2B2 48BE AB4C C9D4 964E 1215 5E80 Loading Loading @@ -2246,19 +2255,12 @@ S: D-90453 Nuernberg S: Germany N: Arnaldo Carvalho de Melo E: acme@conectiva.com.br E: acme@kernel.org E: acme@gnu.org W: http://bazar2.conectiva.com.br/~acme W: http://advogato.org/person/acme E: acme@mandriva.com E: acme@ghostprotocols.net W: http://oops.ghostprotocols.net:81/blog/ P: 1024D/9224DF01 D5DF E3BB E3C8 BCBB F8AD 841A B6AB 4681 9224 DF01 D: wanrouter hacking D: misc Makefile, Config.in, drivers and network stacks fixes D: IPX & LLC network stacks maintainer D: Cyclom 2X synchronous card driver D: wl3501 PCMCIA wireless card driver D: i18n for minicom, net-tools, util-linux, fetchmail, etc S: Conectiva S.A. D: IPX, LLC, DCCP, cyc2x, wl3501_cs, net/ hacks S: Mandriva S: R. Tocantins, 89 - Cristo Rei S: 80050-430 - Curitiba - Paran S: Brazil Loading
Documentation/Changes +10 −0 Original line number Diff line number Diff line Loading @@ -237,6 +237,12 @@ udev udev is a userspace application for populating /dev dynamically with only entries for devices actually present. udev replaces devfs. FUSE ---- Needs libfuse 2.4.0 or later. Absolute minimum is 2.3.0 but mount options 'direct_io' and 'kernel_cache' won't work. Networking ========== Loading Loading @@ -390,6 +396,10 @@ udev ---- o <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html> FUSE ---- o <http://sourceforge.net/projects/fuse> Networking ********** Loading
Documentation/CodingStyle +20 −1 Original line number Diff line number Diff line Loading @@ -410,7 +410,26 @@ Kernel messages do not have to be terminated with a period. Printing numbers in parentheses (%d) adds no value and should be avoided. Chapter 13: References Chapter 13: Allocating memory The kernel provides the following general purpose memory allocators: kmalloc(), kzalloc(), kcalloc(), and vmalloc(). Please refer to the API documentation for further information about them. The preferred form for passing a size of a struct is the following: p = kmalloc(sizeof(*p), ...); The alternative form where struct name is spelled out hurts readability and introduces an opportunity for a bug when the pointer variable type is changed but the corresponding sizeof that is passed to a memory allocator is not. Casting the return value which is a void pointer is redundant. The conversion from void pointer to any other pointer type is guaranteed by the C programming language. Chapter 14: References The C Programming Language, Second Edition by Brian W. Kernighan and Dennis M. Ritchie. Loading
Documentation/DocBook/kernel-hacking.tmpl +1 −1 Original line number Diff line number Diff line Loading @@ -1105,7 +1105,7 @@ static struct block_device_operations opt_fops = { </listitem> <listitem> <para> Function names as strings (__func__). Function names as strings (__FUNCTION__). </para> </listitem> <listitem> Loading
Documentation/SubmittingPatches +85 −1 Original line number Diff line number Diff line Loading @@ -301,8 +301,84 @@ now, but you can do this to mark internal company procedures or just point out some special detail about the sign-off. 12) The canonical patch format 12) More references for submitting patches The canonical patch subject line is: Subject: [PATCH 001/123] subsystem: summary phrase The canonical patch message body contains the following: - A "from" line specifying the patch author. - An empty line. - The body of the explanation, which will be copied to the permanent changelog to describe this patch. - The "Signed-off-by:" lines, described above, which will also go in the changelog. - A marker line containing simply "---". - Any additional comments not suitable for the changelog. - The actual patch (diff output). The Subject line format makes it very easy to sort the emails alphabetically by subject line - pretty much any email reader will support that - since because the sequence number is zero-padded, the numerical and alphabetic sort is the same. The "subsystem" in the email's Subject should identify which area or subsystem of the kernel is being patched. The "summary phrase" in the email's Subject should concisely describe the patch which that email contains. The "summary phrase" should not be a filename. Do not use the same "summary phrase" for every patch in a whole patch series. Bear in mind that the "summary phrase" of your email becomes a globally-unique identifier for that patch. It propagates all the way into the git changelog. The "summary phrase" may later be used in developer discussions which refer to the patch. People will want to google for the "summary phrase" to read discussion regarding that patch. A couple of example Subjects: Subject: [patch 2/5] ext2: improve scalability of bitmap searching Subject: [PATCHv2 001/207] x86: fix eflags tracking The "from" line must be the very first line in the message body, and has the form: From: Original Author <author@example.com> The "from" line specifies who will be credited as the author of the patch in the permanent changelog. If the "from" line is missing, then the "From:" line from the email header will be used to determine the patch author in the changelog. The explanation body will be committed to the permanent source changelog, so should make sense to a competent reader who has long since forgotten the immediate details of the discussion that might have led to this patch. The "---" marker line serves the essential purpose of marking for patch handling tools where the changelog message ends. One good use for the additional comments after the "---" marker is for a diffstat, to show what files have changed, and the number of inserted and deleted lines per file. A diffstat is especially useful on bigger patches. Other comments relevant only to the moment or the maintainer, not suitable for the permanent changelog, should also go here. See more details on the proper patch format in the following references. 13) More references for submitting patches Andrew Morton, "The perfect patch" (tpp). <http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt> Loading @@ -310,6 +386,14 @@ Andrew Morton, "The perfect patch" (tpp). Jeff Garzik, "Linux kernel patch submission format." <http://linux.yyz.us/patch-format.html> Greg KH, "How to piss off a kernel subsystem maintainer" <http://www.kroah.com/log/2005/03/31/> Kernel Documentation/CodingStyle <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle> Linus Torvald's mail on the canonical patch format: <http://lkml.org/lkml/2005/4/7/183> ----------------------------------- Loading
