---

yaml
---
r: 6580
b: refs/heads/master
c: 4689ced
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 62c592edead3c3a045662595f7ade3c12f133373
+refs/heads/master: 4689ced99b18937e28c0f6c190394ccc3c61d651

trunk/CREDITS

@@ -1624,10 +1624,10 @@ E: ajoshi@shell.unixbox.com
 D: fbdev hacking
 
 N: Jesper Juhl
-E: jesper.juhl@gmail.com
-D: Various fixes, cleanups and minor features.
+E: juhl-lkml@dif.dk
+D: Various small janitor fixes, cleanups etc.
 S: Lemnosvej 1, 3.tv
-S: 2300 Copenhagen S.
+S: 2300 Copenhagen S
 S: Denmark
 
 N: Jozsef Kadlecsik
@@ -2380,8 +2380,8 @@ E: tmolina@cablespeed.com
 D: bug fixes, documentation, minor hackery
 
 N: James Morris
-E: jmorris@namei.org
-W: http://namei.org/
+E: jmorris@redhat.com
+W: http://www.intercode.com.au/jmorris/
 D: Netfilter, Linux Security Modules (LSM), SELinux, IPSec,
 D: Crypto API, general networking, miscellaneous.
 S: PO Box 707
@@ -2423,7 +2423,8 @@ S: Toronto, Ontario
 S: Canada
 
 N: Zwane Mwaikambo
-E: zwane@arm.linux.org.uk
+E: zwane@linuxpower.ca
+W: http://function.linuxpower.ca
 D: Various driver hacking
 D: Lowlevel x86 kernel hacking
 D: General debugging

trunk/Documentation/Changes

@@ -65,7 +65,6 @@ o  isdn4k-utils           3.1pre1                 # isdnctrl 2>&1|grep version
 o  nfs-utils              1.0.5                   # showmount --version
 o  procps                 3.2.0                   # ps --version
 o  oprofile               0.9                     # oprofiled --version
-o  udev                   058                     # udevinfo -V
 
 Kernel compilation
 ==================

trunk/Documentation/SubmittingPatches

@@ -149,11 +149,6 @@ USB, framebuffer devices, the VFS, the SCSI subsystem, etc.  See the
 MAINTAINERS file for a mailing list that relates specifically to
 your change.
 
-If changes affect userland-kernel interfaces, please send
-the MAN-PAGES maintainer (as listed in the MAINTAINERS file)
-a man-pages patch, or at least a notification of the change,
-so that some information makes its way into the manual pages.
-
 Even if the maintainer did not respond in step #4, make sure to ALWAYS
 copy the maintainer when you change their code.
 

trunk/Documentation/acpi-hotkey.txt

@@ -33,6 +33,3 @@ The result of the execution of this aml method is
 attached to /proc/acpi/hotkey/poll_method, which is dnyamically
 created.  Please use command "cat /proc/acpi/hotkey/polling_method" 
 to retrieve it.
-
-Note: Use cmdline "acpi_generic_hotkey" to over-ride
-loading any platform specific drivers.

trunk/Documentation/dontdiff

@@ -41,7 +41,6 @@ COPYING
 CREDITS
 CVS
 ChangeSet
-Image
 Kerntypes
 MODS.txt
 Module.symvers
@@ -104,8 +103,6 @@ logo_*.c
 logo_*_clut224.c
 logo_*_mono.c
 lxdialog
-mach-types
-mach-types.h
 make_times_h
 map
 maui_boot.h

trunk/Documentation/fb/vesafb.txt

@@ -144,21 +144,7 @@ vgapal	Use the standard vga registers for palette changes.
 	This is the default.
 pmipal	Use the protected mode interface for palette changes.
 
-mtrr:n	setup memory type range registers for the vesafb framebuffer
-	where n:
-	      0 - disabled (equivalent to nomtrr)
-	      1 - uncachable
-	      2 - write-back
-	      3 - write-combining (default)
-	      4 - write-through
-
-	If you see the following in dmesg, choose the type that matches the
-	old one. In this example, use "mtrr:2".
-...
-mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining
-...
-
-nomtrr  disable mtrr
+mtrr	setup memory type range registers for the vesafb framebuffer.
 
 vremap:n
         remap 'n' MiB of video RAM. If 0 or not specified, remap memory

trunk/Documentation/feature-removal-schedule.txt

@@ -103,11 +103,11 @@ Who:	Jody McIntyre <scjody@steamballoon.com>
 ---------------------------
 
 What:	register_serial/unregister_serial
-When:	September 2005
+When:	December 2005
 Why:	This interface does not allow serial ports to be registered against
 	a struct device, and as such does not allow correct power management
 	of such ports.  8250-based ports should use serial8250_register_port
-	and serial8250_unregister_port, or platform devices instead.
+	and serial8250_unregister_port instead.
 Who:	Russell King <rmk@arm.linux.org.uk>
 
 ---------------------------
@@ -135,15 +135,3 @@ Why:	With the 16-bit PCMCIA subsystem now behaving (almost) like a
 	pcmciautils package available at
 	http://kernel.org/pub/linux/utils/kernel/pcmcia/
 Who:	Dominik Brodowski <linux@brodo.de>
-
----------------------------
-
-What:	ip_queue and ip6_queue (old ipv4-only and ipv6-only netfilter queue)
-When:	December 2005
-Why:	This interface has been obsoleted by the new layer3-independent
-	"nfnetlink_queue".  The Kernel interface is compatible, so the old
-	ip[6]tables "QUEUE" targets still work and will transparently handle
-	all packets into nfnetlink queue number 0.  Userspace users will have
-	to link against API-compatible library on top of libnfnetlink_queue 
-	instead of the current 'libipq'.
-Who:	Harald Welte <laforge@netfilter.org>

trunk/Documentation/filesystems/inotify.txt

@@ -1,22 +1,18 @@
-				   inotify
-	    a powerful yet simple file change notification system
+				    inotify
+	     a powerful yet simple file change notification system
 
 
 
 Document started 15 Mar 2005 by Robert Love <rml@novell.com>
 
-
 (i) User Interface
 
-Inotify is controlled by a set of three system calls and normal file I/O on a
-returned file descriptor.
+Inotify is controlled by a set of three sys calls 
 
-First step in using inotify is to initialise an inotify instance:
+First step in using inotify is to initialise an inotify instance
 
 	int fd = inotify_init ();
 
-Each instance is associated with a unique, ordered queue.
-
 Change events are managed by "watches".  A watch is an (object,mask) pair where
 the object is a file or directory and the mask is a bit mask of one or more
 inotify events that the application wishes to receive.  See <linux/inotify.h>
@@ -26,60 +22,51 @@ Watches are added via a path to the file.
 
 Watches on a directory will return events on any files inside of the directory.
 
-Adding a watch is simple:
+Adding a watch is simple,
 
 	int wd = inotify_add_watch (fd, path, mask);
 
-Where "fd" is the return value from inotify_init(), path is the path to the
-object to watch, and mask is the watch mask (see <linux/inotify.h>).
+You can add a large number of files via something like
+
+	for each file to watch {
+		int wd = inotify_add_watch (fd, file, mask);
+	}
 
 You can update an existing watch in the same manner, by passing in a new mask.
 
-An existing watch is removed via
+An existing watch is removed via the INOTIFY_IGNORE ioctl, for example
 
-	int ret = inotify_rm_watch (fd, wd);
+	inotify_rm_watch (fd, wd);
 
 Events are provided in the form of an inotify_event structure that is read(2)
-from a given inotify instance.  The filename is of dynamic length and follows
-the struct. It is of size len.  The filename is padded with null bytes to
-ensure proper alignment.  This padding is reflected in len.
+from a inotify instance fd.  The filename is of dynamic length and follows the 
+struct. It is of size len.  The filename is padded with null bytes to ensure 
+proper alignment.  This padding is reflected in len.
 
 You can slurp multiple events by passing a large buffer, for example
 
 	size_t len = read (fd, buf, BUF_LEN);
 
-Where "buf" is a pointer to an array of "inotify_event" structures at least
-BUF_LEN bytes in size.  The above example will return as many events as are
-available and fit in BUF_LEN.
+Will return as many events as are available and fit in BUF_LEN.
 
-Each inotify instance fd is also select()- and poll()-able.
+each inotify instance fd is also select()- and poll()-able.
 
-You can find the size of the current event queue via the standard FIONREAD
-ioctl on the fd returned by inotify_init().
+You can find the size of the current event queue via the FIONREAD ioctl.
 
 All watches are destroyed and cleaned up on close.
 
 
-(ii)
-
-Prototypes:
-
-	int inotify_init (void);
-	int inotify_add_watch (int fd, const char *path, __u32 mask);
-	int inotify_rm_watch (int fd, __u32 mask);
-
+(ii) Internal Kernel Implementation
 
-(iii) Internal Kernel Implementation
-
-Each inotify instance is associated with an inotify_device structure.
+Each open inotify instance is associated with an inotify_device structure.
 
 Each watch is associated with an inotify_watch structure.  Watches are chained
 off of each associated device and each associated inode.
 
 See fs/inotify.c for the locking and lifetime rules.
 
 
-(iv) Rationale
+(iii) Rationale
 
 Q: What is the design decision behind not tying the watch to the open fd of
    the watched object?
@@ -88,9 +75,9 @@ A: Watches are associated with an open inotify device, not an open file.
    This solves the primary problem with dnotify: keeping the file open pins
    the file and thus, worse, pins the mount.  Dnotify is therefore infeasible
    for use on a desktop system with removable media as the media cannot be
-   unmounted.  Watching a file should not require that it be open.
+   unmounted.
 
-Q: What is the design decision behind using an-fd-per-instance as opposed to
+Q: What is the design decision behind using an-fd-per-device as opposed to
    an fd-per-watch?
 
 A: An fd-per-watch quickly consumes more file descriptors than are allowed,
@@ -99,8 +86,8 @@ A: An fd-per-watch quickly consumes more file descriptors than are allowed,
    can use epoll, but requiring both is a silly and extraneous requirement.
    A watch consumes less memory than an open file, separating the number
    spaces is thus sensible.  The current design is what user-space developers
-   want: Users initialize inotify, once, and add n watches, requiring but one
-   fd and no twiddling with fd limits.  Initializing an inotify instance two
+   want: Users initialize inotify, once, and add n watches, requiring but one fd
+   and no twiddling with fd limits.  Initializing an inotify instance two
    thousand times is silly.  If we can implement user-space's preferences 
    cleanly--and we can, the idr layer makes stuff like this trivial--then we 
    should.
@@ -124,6 +111,9 @@ A: An fd-per-watch quickly consumes more file descriptors than are allowed,
      example, love it.  Trust me, I asked.  It is not a surprise: Who'd want
      to manage and block on 1000 fd's via select?
 
+   - You'd have to manage the fd's, as an example: Call close() when you
+     received a delete event.
+
    - No way to get out of band data.
 
    - 1024 is still too low.  ;-)
@@ -132,11 +122,6 @@ A: An fd-per-watch quickly consumes more file descriptors than are allowed,
    scales to 1000s of directories, juggling 1000s of fd's just does not seem
    the right interface.  It is too heavy.
 
-   Additionally, it _is_ possible to  more than one instance  and
-   juggle more than one queue and thus more than one associated fd.  There
-   need not be a one-fd-per-process mapping; it is one-fd-per-queue and a
-   process can easily want more than one queue.
-
 Q: Why the system call approach?
 
 A: The poor user-space interface is the second biggest problem with dnotify.
@@ -146,6 +131,8 @@ A: The poor user-space interface is the second biggest problem with dnotify.
    Obtaining the fd and managing the watches could have been done either via a
    device file or a family of new system calls.  We decided to implement a
    family of system calls because that is the preffered approach for new kernel
-   interfaces.  The only real difference was whether we wanted to use open(2)
-   and ioctl(2) or a couple of new system calls.  System calls beat ioctls.
+   features and it means our user interface requirements.
+
+   Additionally, it _is_ possible to  more than one instance  and
+   juggle more than one queue and thus more than one associated fd.