---

yaml
---
r: 57300
b: refs/heads/master
c: ccb8f43
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 20c4856b1d1939647f71dce5e54fe69fde80013f
+refs/heads/master: ccb8f430ac4cfd1acd12ff591918b8b67d73c977

trunk/Documentation/BUG-HUNTING

@@ -191,30 +191,6 @@ e.g. crash dump output as shown by Dave Miller.
 >        mov        0x8(%ebp), %ebx         ! %ebx = skb->sk
 >        mov        0x13c(%ebx), %eax       ! %eax = inet_sk(sk)->opt
 
-In addition, you can use GDB to figure out the exact file and line
-number of the OOPS from the vmlinux file. If you have
-CONFIG_DEBUG_INFO enabled, you can simply copy the EIP value from the
-OOPS:
-
- EIP:    0060:[<c021e50e>]    Not tainted VLI
-
-And use GDB to translate that to human-readable form:
-
-  gdb vmlinux
-  (gdb) l *0xc021e50e
-
-If you don't have CONFIG_DEBUG_INFO enabled, you use the function
-offset from the OOPS:
-
- EIP is at vt_ioctl+0xda8/0x1482
-
-And recompile the kernel with CONFIG_DEBUG_INFO enabled:
-
-  make vmlinux
-  gdb vmlinux
-  (gdb) p vt_ioctl
-  (gdb) l *(0x<address of vt_ioctl> + 0xda8)
-
 Another very useful option of the Kernel Hacking section in menuconfig is
 Debug memory allocations. This will help you see whether data has been
 initialised and not set before use etc. To see the values that get assigned

trunk/Documentation/CodingStyle

@@ -495,40 +495,29 @@ re-formatting you may want to take a look at the man page.  But
 remember: "indent" is not a fix for bad programming.
 
 
-		Chapter 10: Kconfig configuration files
+		Chapter 10: Configuration-files
 
-For all of the Kconfig* configuration files throughout the source tree,
-the indentation is somewhat different.  Lines under a "config" definition
-are indented with one tab, while help text is indented an additional two
-spaces.  Example:
+For configuration options (arch/xxx/Kconfig, and all the Kconfig files),
+somewhat different indentation is used.
 
-config AUDIT
-	bool "Auditing support"
-	depends on NET
-	help
-	  Enable auditing infrastructure that can be used with another
-	  kernel subsystem, such as SELinux (which requires this for
-	  logging of avc messages output).  Does not do system-call
-	  auditing without CONFIG_AUDITSYSCALL.
-
-Features that might still be considered unstable should be defined as
-dependent on "EXPERIMENTAL":
-
-config SLUB
-	depends on EXPERIMENTAL && !ARCH_USES_SLAB_PAGE_STRUCT
-	bool "SLUB (Unqueued Allocator)"
-	...
+Help text is indented with 2 spaces.
 
-while seriously dangerous features (such as write support for certain
-filesystems) should advertise this prominently in their prompt string:
-
-config ADFS_FS_RW
-	bool "ADFS write support (DANGEROUS)"
-	depends on ADFS_FS
-	...
+if CONFIG_EXPERIMENTAL
+	tristate CONFIG_BOOM
+	default n
+	help
+	  Apply nitroglycerine inside the keyboard (DANGEROUS)
+	bool CONFIG_CHEER
+	depends on CONFIG_BOOM
+	default y
+	help
+	  Output nice messages when you explode
+endif
 
-For full documentation on the configuration files, see the file
-Documentation/kbuild/kconfig-language.txt.
+Generally, CONFIG_EXPERIMENTAL should surround all options not considered
+stable. All options that are known to trash data (experimental write-
+support for file-systems, for instance) should be denoted (DANGEROUS), other
+experimental options should be denoted (EXPERIMENTAL).
 
 
 		Chapter 11: Data structures

trunk/Documentation/DocBook/gadget.tmpl

@@ -52,7 +52,7 @@
 
 <toc></toc>
 
-<chapter id="intro"><title>Introduction</title>
+<chapter><title>Introduction</title>
 
 <para>This document presents a Linux-USB "Gadget"
 kernel mode

trunk/Documentation/DocBook/usb.tmpl

@@ -185,7 +185,7 @@
 
     </chapter>
 
-<chapter id="types"><title>USB-Standard Types</title>
+<chapter><title>USB-Standard Types</title>
 
     <para>In <filename>&lt;linux/usb/ch9.h&gt;</filename> you will find
     the USB data types defined in chapter 9 of the USB specification.
@@ -197,7 +197,7 @@
 
     </chapter>
 
-<chapter id="hostside"><title>Host-Side Data Types and Macros</title>
+<chapter><title>Host-Side Data Types and Macros</title>
 
     <para>The host side API exposes several layers to drivers, some of
     which are more necessary than others.
@@ -211,7 +211,7 @@
 
     </chapter>
 
-    <chapter id="usbcore"><title>USB Core APIs</title>
+    <chapter><title>USB Core APIs</title>
 
     <para>There are two basic I/O models in the USB API.
     The most elemental one is asynchronous:  drivers submit requests
@@ -248,7 +248,7 @@
 !Edrivers/usb/core/hub.c
     </chapter>
 
-    <chapter id="hcd"><title>Host Controller APIs</title>
+    <chapter><title>Host Controller APIs</title>
 
     <para>These APIs are only for use by host controller drivers,
     most of which implement standard register interfaces such as
@@ -285,7 +285,7 @@
 !Idrivers/usb/core/buffer.c
     </chapter>
 
-    <chapter id="usbfs">
+    <chapter>
 	<title>The USB Filesystem (usbfs)</title>
 
 	<para>This chapter presents the Linux <emphasis>usbfs</emphasis>.
@@ -317,7 +317,7 @@
 	not it has a kernel driver.
 	</para>
 
-	<sect1 id="usbfs-files">
+	<sect1>
 	    <title>What files are in "usbfs"?</title>
 
 	    <para>Conventionally mounted at
@@ -356,7 +356,7 @@
 
 	</sect1>
 
-	<sect1 id="usbfs-fstab">
+	<sect1>
 	    <title>Mounting and Access Control</title>
 
 	    <para>There are a number of mount options for usbfs, which will
@@ -439,7 +439,7 @@
 
 	</sect1>
 
-	<sect1 id="usbfs-devices">
+	<sect1>
 	    <title>/proc/bus/usb/devices</title>
 
 	    <para>This file is handy for status viewing tools in user
@@ -473,7 +473,7 @@ for (;;) {
 	    </para>
 	</sect1>
 
-	<sect1 id="usbfs-bbbddd">
+	<sect1>
 	    <title>/proc/bus/usb/BBB/DDD</title>
 
 	    <para>Use these files in one of these basic ways:
@@ -510,7 +510,7 @@ for (;;) {
 	    </sect1>
 
 
-	<sect1 id="usbfs-lifecycle">
+	<sect1>
 	    <title>Life Cycle of User Mode Drivers</title>
 
 	    <para>Such a driver first needs to find a device file
@@ -565,7 +565,7 @@ for (;;) {
 
 	    </sect1>
 
-	<sect1 id="usbfs-ioctl"><title>The ioctl() Requests</title>
+	<sect1><title>The ioctl() Requests</title>
 
 	    <para>To use these ioctls, you need to include the following
 	    headers in your userspace program:
@@ -604,7 +604,7 @@ for (;;) {
 	    </para>
 
 
-	    <sect2 id="usbfs-mgmt">
+	    <sect2>
 		<title>Management/Status Requests</title>
 
 		<para>A number of usbfs requests don't deal very directly
@@ -736,7 +736,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param)
 
 		</sect2>
 
-	    <sect2 id="usbfs-sync">
+	    <sect2>
 		<title>Synchronous I/O Support</title>
 
 		<para>Synchronous requests involve the kernel blocking
@@ -865,7 +865,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param)
 		</variablelist>
 	    </sect2>
 
-	    <sect2 id="usbfs-async">
+	    <sect2>
 		<title>Asynchronous I/O Support</title>
 
 		<para>As mentioned above, there are situations where it may be

trunk/Documentation/HOWTO

@@ -396,6 +396,26 @@ bugme-janitor mailing list (every change in the bugzilla is mailed here)
 
 
 
+Managing bug reports
+--------------------
+
+One of the best ways to put into practice your hacking skills is by fixing
+bugs reported by other people. Not only you will help to make the kernel
+more stable, you'll learn to fix real world problems and you will improve
+your skills, and other developers will be aware of your presence. Fixing
+bugs is one of the best ways to get merits among other developers, because
+not many people like wasting time fixing other people's bugs.
+
+To work in the already reported bug reports, go to http://bugzilla.kernel.org.
+If you want to be advised of the future bug reports, you can subscribe to the
+bugme-new mailing list (only new bug reports are mailed here) or to the
+bugme-janitor mailing list (every change in the bugzilla is mailed here)
+
+	http://lists.osdl.org/mailman/listinfo/bugme-new
+	http://lists.osdl.org/mailman/listinfo/bugme-janitors
+
+
+
 Mailing lists
 -------------
 

trunk/Documentation/SubmitChecklist

@@ -84,9 +84,3 @@ kernel patches.
 24: Avoid whitespace damage such as indenting with spaces or whitespace
     at the end of lines.  You can test this by feeding the patch to
     "git apply --check --whitespace=error-all"
-
-25: Check your patch for general style as detailed in
-    Documentation/CodingStyle.  Check for trivial violations with the
-    patch style checker prior to submission (scripts/checkpatch.pl).
-    You should be able to justify all violations that remain in
-    your patch.

trunk/Documentation/SubmittingPatches

@@ -118,20 +118,7 @@ then only post say 15 or so at a time and wait for review and integration.
 
 
 
-4) Style check your changes.
-
-Check your patch for basic style violations, details of which can be
-found in Documentation/CodingStyle.  Failure to do so simply wastes
-the reviewers time and will get your patch rejected, probabally
-without even being read.
-
-At a minimum you should check your patches with the patch style
-checker prior to submission (scripts/patchcheck.pl).  You should
-be able to justify all violations that remain in your patch.
-
-
-
-5) Select e-mail destination.
+4) Select e-mail destination.
 
 Look through the MAINTAINERS file and the source code, and determine
 if your change applies to a specific subsystem of the kernel, with
@@ -159,7 +146,7 @@ discussed should the patch then be submitted to Linus.
 
 
 
-6) Select your CC (e-mail carbon copy) list.
+5) Select your CC (e-mail carbon copy) list.
 
 Unless you have a reason NOT to do so, CC linux-kernel@vger.kernel.org.
 
@@ -200,7 +187,8 @@ URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/>
 
 
 
-7) No MIME, no links, no compression, no attachments.  Just plain text.
+
+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
@@ -235,9 +223,9 @@ pref("mailnews.display.disable_format_flowed_support", true);
 
 
 
-8) E-mail size.
+7) E-mail size.
 
-When sending patches to Linus, always follow step #7.
+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 40 kB in size,
@@ -246,7 +234,7 @@ server, and provide instead a URL (link) pointing to your patch.
 
 
 
-9) Name your kernel version.
+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.
@@ -256,7 +244,7 @@ Linus will not apply it.
 
 
 
-10) Don't get discouraged.  Re-submit.
+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
@@ -282,7 +270,7 @@ When in doubt, solicit comments on linux-kernel mailing list.
 
 
 
-11) Include PATCH in the subject
+10) Include PATCH in the subject
 
 Due to high e-mail traffic to Linus, and to linux-kernel, it is common
 convention to prefix your subject line with [PATCH].  This lets Linus
@@ -291,7 +279,7 @@ e-mail discussions.
 
 
 
-12) Sign your work
+11) Sign your work
 
 To improve tracking of who did what, especially with patches that can
 percolate to their final resting place in the kernel through several
@@ -340,8 +328,7 @@ now, but you can do this to mark internal company procedures or just
 point out some special detail about the sign-off. 
 
 
-
-13) The canonical patch format
+12) The canonical patch format
 
 The canonical patch subject line is:
 
@@ -440,10 +427,6 @@ section Linus Computer Science 101.
 Nuff said.  If your code deviates too much from this, it is likely
 to be rejected without further review, and without comment.
 
-Check your patches with the patch style checker prior to submission
-(scripts/checkpatch.pl).  You should be able to justify all
-violations that remain in your patch.
-
 
 
 2) #ifdefs are ugly