---

yaml --- r: 10197 b: refs/heads/master c: bb0ce60 h: refs/heads/master i: 10195: 5a93a2c v: v3
git-mirror · Sep 14, 2005 · c2517b0 · c2517b0
1 parent 766e85f
commit c2517b0
Show file tree

Hide file tree

Showing 1,575 changed files with 20,775 additions and 50,052 deletions.
diff --git a/[refs] b/[refs]
@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 5dd962494f76fb3ef1196cd420b5d6260d7a3766
+refs/heads/master: bb0ce608a3386268bd76ee6642a4cc8e6818a29b
diff --git a/trunk/.gitignore b/trunk/.gitignore
diff --git a/trunk/CREDITS b/trunk/CREDITS
@@ -2211,15 +2211,6 @@ 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
@@ -2255,12 +2246,19 @@ S: D-90453 Nuernberg
 S: Germany
 
 N: Arnaldo Carvalho de Melo
-E: acme@mandriva.com
-E: acme@ghostprotocols.net
-W: http://oops.ghostprotocols.net:81/blog/
+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
 P: 1024D/9224DF01 D5DF E3BB E3C8 BCBB F8AD  841A B6AB 4681 9224 DF01
-D: IPX, LLC, DCCP, cyc2x, wl3501_cs, net/ hacks
-S: Mandriva
+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.
 S: R. Tocantins, 89 - Cristo Rei
 S: 80050-430 - Curitiba - Paran�
 S: Brazil

diff --git a/trunk/Documentation/Changes b/trunk/Documentation/Changes
@@ -237,12 +237,6 @@ 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
 ==========
 
@@ -396,10 +390,6 @@ udev
 ----
 o <http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html>
 
-FUSE
-----
-o <http://sourceforge.net/projects/fuse>
-
 Networking
 **********
 

diff --git a/trunk/Documentation/CodingStyle b/trunk/Documentation/CodingStyle
@@ -410,26 +410,7 @@ 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: 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
+		Chapter 13: References
 
 The C Programming Language, Second Edition
 by Brian W. Kernighan and Dennis M. Ritchie.

diff --git a/trunk/Documentation/DocBook/kernel-hacking.tmpl b/trunk/Documentation/DocBook/kernel-hacking.tmpl
@@ -1105,7 +1105,7 @@ static struct block_device_operations opt_fops = {
     </listitem>
     <listitem>
      <para>
-      Function names as strings (__FUNCTION__).
+      Function names as strings (__func__).
      </para>
     </listitem>
     <listitem>

diff --git a/trunk/Documentation/SubmittingPatches b/trunk/Documentation/SubmittingPatches
@@ -301,99 +301,15 @@ 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
 
-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
+12) More references for submitting patches
 
 Andrew Morton, "The perfect patch" (tpp).
   <http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt>
 
 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>
 
 
 -----------------------------------