---

yaml
---
r: 74910
b: refs/heads/master
c: 980110c
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: c4c283357d865aad1f124c069f5f6e3f39e76790
+refs/heads/master: 980110c5da56cb56d3356f5a5251fdc920f83ba6

trunk/Documentation/00-INDEX

@@ -262,6 +262,8 @@ mtrr.txt
 	- how to use PPro Memory Type Range Registers to increase performance.
 mutex-design.txt
 	- info on the generic mutex subsystem.
+namespaces/
+	- directory with various information about namespaces
 nbd.txt
 	- info on a TCP implementation of a network block device.
 netlabel/

trunk/Documentation/DocBook/Makefile

@@ -11,7 +11,7 @@ DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml videobook.xml \
 	    procfs-guide.xml writing_usb_driver.xml \
 	    kernel-api.xml filesystems.xml lsm.xml usb.xml \
 	    gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
-	    genericirq.xml s390-drivers.xml
+	    genericirq.xml s390-drivers.xml uio-howto.xml
 
 ###
 # The build process is as follows (targets):

trunk/Documentation/DocBook/uio-howto.tmpl

@@ -29,6 +29,12 @@
 </abstract>
 
 <revhistory>
+	<revision>
+	<revnumber>0.4</revnumber>
+	<date>2007-11-26</date>
+	<authorinitials>hjk</authorinitials>
+	<revremark>Removed section about uio_dummy.</revremark>
+	</revision>
 	<revision>
 	<revnumber>0.3</revnumber>
 	<date>2007-04-29</date>
@@ -94,6 +100,26 @@ interested in translating it, please email me
 	user space. This simplifies development and reduces the risk of
 	serious bugs within a kernel module.
 	</para>
+	<para>
+	Please note that UIO is not an universal driver interface. Devices
+	that are already handled well by other kernel subsystems (like
+	networking or serial or USB) are no candidates for an UIO driver.
+	Hardware that is ideally suited for an UIO driver fulfills all of
+	the following:
+	</para>
+<itemizedlist>
+<listitem>
+	<para>The device has memory that can be mapped. The device can be
+	controlled completely by writing to this memory.</para>
+</listitem>
+<listitem>
+	<para>The device usually generates interrupts.</para>
+</listitem>
+<listitem>
+	<para>The device does not fit into one of the standard kernel
+	subsystems.</para>
+</listitem>
+</itemizedlist>
 </sect1>
 
 <sect1 id="thanks">
@@ -174,8 +200,9 @@ interested in translating it, please email me
 	For cards that don't generate interrupts but need to be
 	polled, there is the possibility to set up a timer that
 	triggers the interrupt handler at configurable time intervals.
-	See <filename>drivers/uio/uio_dummy.c</filename> for an
-	example of this technique.
+	This interrupt simulation is done by calling
+	<function>uio_event_notify()</function>
+	from the timer's event handler.
 	</para>
 
 	<para>
@@ -263,63 +290,11 @@ offset = N * getpagesize();
 </sect1>
 </chapter>
 
-<chapter id="using-uio_dummy" xreflabel="Using uio_dummy">
-<?dbhtml filename="using-uio_dummy.html"?>
-<title>Using uio_dummy</title>
-	<para>
-	Well, there is no real use for uio_dummy. Its only purpose is
-	to test most parts of the UIO system (everything except
-	hardware interrupts), and to serve as an example for the
-	kernel module that you will have to write yourself.
-	</para>
-
-<sect1 id="what_uio_dummy_does">
-<title>What uio_dummy does</title>
-	<para>
-	The kernel module <filename>uio_dummy.ko</filename> creates a
-	device that uses a timer to generate periodic interrupts. The
-	interrupt handler does nothing but increment a counter. The
-	driver adds two custom attributes, <varname>count</varname>
-	and <varname>freq</varname>, that appear under
-	<filename>/sys/devices/platform/uio_dummy/</filename>.
-	</para>
-
-	<para>
-	The attribute <varname>count</varname> can be read and
-	written.  The associated file
-	<filename>/sys/devices/platform/uio_dummy/count</filename>
-	appears as a normal text file and contains the total number of
-	timer interrupts. If you look at it (e.g. using
-	<function>cat</function>), you'll notice it is slowly counting
-	up.
-	</para>
-
-	<para>
-	The attribute <varname>freq</varname> can be read and written.
-	The content of
-	<filename>/sys/devices/platform/uio_dummy/freq</filename>
-	represents the number of system timer ticks between two timer
-	interrupts. The default value of <varname>freq</varname> is
-	the value of the kernel variable <varname>HZ</varname>, which
-	gives you an interval of one second. Lower values will
-	increase the frequency. Try the following:
-	</para>
-<programlisting format="linespecific">
-cd /sys/devices/platform/uio_dummy/
-echo 100 > freq
-</programlisting>
-	<para>
-	Use <function>cat count</function> to see how the interrupt
-	frequency changes.
-	</para>
-</sect1>
-</chapter>
-
 <chapter id="custom_kernel_module" xreflabel="Writing your own kernel module">
 <?dbhtml filename="custom_kernel_module.html"?>
 <title>Writing your own kernel module</title>
 	<para>
-	Please have a look at <filename>uio_dummy.c</filename> as an
+	Please have a look at <filename>uio_cif.c</filename> as an
 	example. The following paragraphs explain the different
 	sections of this file.
 	</para>
@@ -354,9 +329,8 @@ See the description below for details.
 interrupt, it's your modules task to determine the irq number during
 initialization. If you don't have a hardware generated interrupt but
 want to trigger the interrupt handler in some other way, set
-<varname>irq</varname> to <varname>UIO_IRQ_CUSTOM</varname>. The
-uio_dummy module does this as it triggers the event mechanism in a timer
-routine. If you had no interrupt at all, you could set
+<varname>irq</varname> to <varname>UIO_IRQ_CUSTOM</varname>.
+If you had no interrupt at all, you could set
 <varname>irq</varname> to <varname>UIO_IRQ_NONE</varname>, though this
 rarely makes sense.
 </para></listitem>

trunk/Documentation/i2c/summary

@@ -1,5 +1,3 @@
-This is an explanation of what i2c is, and what is supported in this package.
-
 I2C and SMBus
 =============
 
@@ -33,52 +31,17 @@ When we talk about I2C, we use the following terms:
             Client
 
 An Algorithm driver contains general code that can be used for a whole class
-of I2C adapters. Each specific adapter driver depends on one algorithm
-driver.
+of I2C adapters. Each specific adapter driver either depends on one algorithm
+driver, or includes its own implementation.
 
 A Driver driver (yes, this sounds ridiculous, sorry) contains the general
 code to access some type of device. Each detected device gets its own
 data in the Client structure. Usually, Driver and Client are more closely
 integrated than Algorithm and Adapter.
 
-For a given configuration, you will need a driver for your I2C bus (usually
-a separate Adapter and Algorithm driver), and drivers for your I2C devices
-(usually one driver for each device). There are no I2C device drivers
-in this package. See the lm_sensors project http://www.lm-sensors.nu
-for device drivers.
+For a given configuration, you will need a driver for your I2C bus, and
+drivers for your I2C devices (usually one driver for each device).
 
 At this time, Linux only operates I2C (or SMBus) in master mode; you can't
 use these APIs to make a Linux system behave as a slave/device, either to
 speak a custom protocol or to emulate some other device.
-
-
-Included Bus Drivers
-====================
-Note that only stable drivers are patched into the kernel by 'mkpatch'.
-
-
-Base modules
-------------
-
-i2c-core: The basic I2C code, including the /proc/bus/i2c* interface
-i2c-dev:  The /dev/i2c-* interface
-i2c-proc: The /proc/sys/dev/sensors interface for device (client) drivers
-
-Algorithm drivers
------------------
-
-i2c-algo-bit:    A bit-banging algorithm
-i2c-algo-pcf:    A PCF 8584 style algorithm
-i2c-algo-ibm_ocp: An algorithm for the I2C device in IBM 4xx processors (NOT BUILT BY DEFAULT)
-
-Adapter drivers
----------------
-
-i2c-elektor:     Elektor ISA card (uses i2c-algo-pcf)
-i2c-elv:         ELV parallel port adapter (uses i2c-algo-bit)
-i2c-pcf-epp:     PCF8584 on a EPP parallel port (uses i2c-algo-pcf) (NOT mkpatched)
-i2c-philips-par: Philips style parallel port adapter (uses i2c-algo-bit)
-i2c-adap-ibm_ocp: IBM 4xx processor I2C device (uses i2c-algo-ibm_ocp) (NOT BUILT BY DEFAULT)
-i2c-pport:       Primitive parallel port adapter (uses i2c-algo-bit)
-i2c-velleman:    Velleman K8000 parallel port adapter (uses i2c-algo-bit)
-

trunk/Documentation/lguest/lguest.c

@@ -1040,6 +1040,11 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
 		/ getpagesize();
 	p = get_pages(pages);
 
+	/* Initialize the virtqueue */
+	vq->next = NULL;
+	vq->last_avail_idx = 0;
+	vq->dev = dev;
+
 	/* Initialize the configuration. */
 	vq->config.num = num_descs;
 	vq->config.irq = devices.next_irq++;
@@ -1057,9 +1062,6 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
 	for (i = &dev->vq; *i; i = &(*i)->next);
 	*i = vq;
 
-	/* Link virtqueue back to device. */
-	vq->dev = dev;
-
 	/* Set the routine to call when the Guest does something to this
 	 * virtqueue. */
 	vq->handle_output = handle_output;
@@ -1093,6 +1095,7 @@ static struct device *new_device(const char *name, u16 type, int fd,
 	dev->desc = new_dev_desc(type);
 	dev->handle_input = handle_input;
 	dev->name = name;
+	dev->vq = NULL;
 	return dev;
 }
 

trunk/Documentation/namespaces/compatibility-list.txt

@@ -0,0 +1,39 @@
+	Namespaces compatibility list
+
+This document contains the information about the problems user
+may have when creating tasks living in different namespaces.
+
+Here's the summary. This matrix shows the known problems, that
+occur when tasks share some namespace (the columns) while living
+in different other namespaces (the rows):
+
+	UTS	IPC	VFS	PID	User	Net
+UTS	 X
+IPC		 X	 1
+VFS			 X
+PID		 1	 1	 X
+User		 2	 2		 X
+Net						 X
+
+1. Both the IPC and the PID namespaces provide IDs to address
+   object inside the kernel. E.g. semaphore with IPCID or
+   process group with pid.
+
+   In both cases, tasks shouldn't try exposing this ID to some
+   other task living in a different namespace via a shared filesystem
+   or IPC shmem/message. The fact is that this ID is only valid
+   within the namespace it was obtained in and may refer to some
+   other object in another namespace.
+
+2. Intentionally, two equal user IDs in different user namespaces
+   should not be equal from the VFS point of view. In other
+   words, user 10 in one user namespace shouldn't have the same
+   access permissions to files, belonging to user 10 in another
+   namespace.
+
+   The same is true for the IPC namespaces being shared - two users
+   from different user namespaces should not access the same IPC objects
+   even having equal UIDs.
+
+   But currently this is not so.
+

trunk/Documentation/networking/bonding.txt

@@ -554,6 +554,30 @@ xmit_hash_policy
 
 		This algorithm is 802.3ad compliant.
 
+	layer2+3
+
+		This policy uses a combination of layer2 and layer3
+		protocol information to generate the hash.
+
+		Uses XOR of hardware MAC addresses and IP addresses to
+		generate the hash.  The formula is
+
+		(((source IP XOR dest IP) AND 0xffff) XOR
+			( source MAC XOR destination MAC ))
+				modulo slave count
+
+		This algorithm will place all traffic to a particular
+		network peer on the same slave.  For non-IP traffic,
+		the formula is the same as for the layer2 transmit
+		hash policy.
+
+		This policy is intended to provide a more balanced
+		distribution of traffic than layer2 alone, especially
+		in environments where a layer3 gateway device is
+		required to reach most destinations.
+
+		This algorithm is 802.3ad complient.
+
 	layer3+4
 
 		This policy uses upper layer protocol information,
@@ -589,8 +613,9 @@ xmit_hash_policy
 		or may not tolerate this noncompliance.
 
 	The default value is layer2.  This option was added in bonding
-version 2.6.3.  In earlier versions of bonding, this parameter does
-not exist, and the layer2 policy is the only policy.
+	version 2.6.3.  In earlier versions of bonding, this parameter
+	does not exist, and the layer2 policy is the only policy.  The
+	layer2+3 value was added for bonding version 3.2.2.
 
 
 3. Configuring Bonding Devices

trunk/Documentation/nfsroot.txt

@@ -92,8 +92,14 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
   autoconfiguration.
 
   The <autoconf> parameter can appear alone as the value to the `ip'
-  parameter (without all the ':' characters before) in which case auto-
-  configuration is used.
+  parameter (without all the ':' characters before).  If the value is
+  "ip=off" or "ip=none", no autoconfiguration will take place, otherwise
+  autoconfiguration will take place.  The most common way to use this
+  is "ip=dhcp".
+
+  Note that "ip=off" is not the same thing as "ip=::::::off", because in
+  the latter autoconfiguration will take place if any of DHCP, BOOTP or RARP
+  are compiled in the kernel.
 
   <client-ip>	IP address of the client.
 
@@ -142,7 +148,7 @@ ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
 		into the kernel will be used, regardless of the value of
 		this option.
 
-                  off or none: don't use autoconfiguration (default)
+                  off or none: don't use autoconfiguration
 		  on or any:   use any protocol available in the kernel
 		  dhcp:        use DHCP
 		  bootp:       use BOOTP

trunk/Documentation/parport-lowlevel.txt

@@ -339,6 +339,10 @@ Use this function to register your device driver on a parallel port
 ('port').  Once you have done that, you will be able to use
 parport_claim and parport_release in order to use the port.
 
+The ('name') argument is the name of the device that appears in /proc
+filesystem. The string must be valid for the whole lifetime of the
+device (until parport_unregister_device is called).
+
 This function will register three callbacks into your driver:
 'preempt', 'wakeup' and 'irq'.  Each of these may be NULL in order to
 indicate that you do not want a callback.

trunk/Documentation/powerpc/booting-without-of.txt

@@ -1645,8 +1645,9 @@ platforms are moved over to use the flattened-device-tree model.
      MAC addresses passed by the firmware when no information other
      than indices is available to associate an address with a device.
    - phy-connection-type : a string naming the controller/PHY interface type,
-     i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "tbi",
-     or "rtbi".
+     i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id" (Internal
+     Delay), "rgmii-txid" (delay on TX only), "rgmii-rxid" (delay on RX only),
+     "tbi", or "rtbi".
 
    Example:
 	ucc@2000 {