---

yaml
---
r: 67705
b: refs/heads/master
c: 77f1fd6
h: refs/heads/master
i:
  67703: 022d1db
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 7e6973e9aca997d95995a7b17768f7b77b7c6c24
+refs/heads/master: 77f1fd6ecd04556cbac1ca72e7a284ae313ea538

trunk/CREDITS

@@ -665,11 +665,6 @@ D: Minor updates to SCSI types, added /proc/pid/maps protection
 S: (ask for current address)
 S: USA
 
-N: Robin Cornelius
-E: robincornelius@users.sourceforge.net
-D: Ralink rt2x00 WLAN driver
-S: Cornwall, U.K.
-
 N: Mark Corner
 E: mcorner@umich.edu
 W: http://www.eecs.umich.edu/~mcorner/
@@ -684,11 +679,6 @@ D: Kernel module SMART utilities
 S: Santa Cruz, California
 S: USA
 
-N: Luis Correia
-E: lfcorreia@users.sf.net
-D: Ralink rt2x00 WLAN driver
-S: Belas, Portugal
-
 N: Alan Cox
 W: http://www.linux.org.uk/diary/
 D: Linux Networking (0.99.10->2.0.29)
@@ -843,12 +833,6 @@ S: Lancs
 S: PR4 6AX
 S: United Kingdom
 
-N: Ivo van Doorn
-E: IvDoorn@gmail.com
-W: http://www.mendiosus.nl
-D: Ralink rt2x00 WLAN driver
-S: Haarlem, The Netherlands
-
 N: John G Dorsey
 E: john+@cs.cmu.edu
 D: ARM Linux ports to Assabet/Neponset, Spot
@@ -3533,12 +3517,6 @@ S: Maastrichterweg 63
 S: 5554 GG Valkenswaard
 S: The Netherlands
 
-N: Mark Wallis
-E: mwallis@serialmonkey.com
-W: http://mark.serialmonkey.com
-D: Ralink rt2x00 WLAN driver
-S: Newcastle, Australia
-
 N: Peter Shaobo Wang
 E: pwang@mmdcorp.com
 W: http://www.mmdcorp.com/pw/linux
@@ -3673,15 +3651,6 @@ S: Alte Regensburger Str. 11a
 S: 93149 Nittenau
 S: Germany
 
-N: Gertjan van Wingerde
-E: gwingerde@home.nl
-D: Ralink rt2x00 WLAN driver
-D: Minix V2 file-system
-D: Misc fixes
-S: Geessinkweg 177
-S: 7544 TX Enschede
-S: The Netherlands
-
 N: Lars Wirzenius
 E: liw@iki.fi
 D: Linux System Administrator's Guide, author, former maintainer

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
 
 ###
 # The build process is as follows (targets):

trunk/Documentation/DocBook/kernel-api.tmpl

@@ -240,23 +240,17 @@ X!Ilib/string.c
      <sect1><title>Driver Support</title>
 !Enet/core/dev.c
 !Enet/ethernet/eth.c
-!Enet/sched/sch_generic.c
 !Iinclude/linux/etherdevice.h
-!Iinclude/linux/netdevice.h
-     </sect1>
-     <sect1><title>PHY Support</title>
 !Edrivers/net/phy/phy.c
 !Idrivers/net/phy/phy.c
 !Edrivers/net/phy/phy_device.c
 !Idrivers/net/phy/phy_device.c
 !Edrivers/net/phy/mdio_bus.c
 !Idrivers/net/phy/mdio_bus.c
-     </sect1>
 <!-- FIXME: Removed for now since no structured comments in source
-     <sect1><title>Wireless</title>
 X!Enet/core/wireless.c
-     </sect1>
 -->
+     </sect1>
      <sect1><title>Synchronous PPP</title>
 !Edrivers/net/wan/syncppp.c
      </sect1>

trunk/Documentation/block/biodoc.txt

@@ -477,9 +477,9 @@ With this multipage bio design:
   the same bi_io_vec array, but with the index and size accordingly modified)
 - A linked list of bios is used as before for unrelated merges (*) - this
   avoids reallocs and makes independent completions easier to handle.
-- Code that traverses the req list can find all the segments of a bio
-  by using rq_for_each_segment.  This handles the fact that a request
-  has multiple bios, each of which can have multiple segments.
+- Code that traverses the req list needs to make a distinction between
+  segments of a request (bio_for_each_segment) and the distinct completion
+  units/bios (rq_for_each_bio).
 - Drivers which can't process a large bio in one shot can use the bi_idx
   field to keep track of the next bio_vec entry to process.
   (e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE)
@@ -664,14 +664,14 @@ in lvm or md.
 
 3.2.1 Traversing segments and completion units in a request
 
-The macro rq_for_each_segment() should be used for traversing the bios
-in the request list (drivers should avoid directly trying to do it
-themselves). Using these helpers should also make it easier to cope
-with block changes in the future.
+The macros bio_for_each_segment() and rq_for_each_bio() should be used for
+traversing the bios in the request list (drivers should avoid directly
+trying to do it themselves). Using these helpers should also make it easier
+to cope with block changes in the future.
 
-	struct req_iterator iter;
-	rq_for_each_segment(bio_vec, rq, iter)
-		/* bio_vec is now current segment */
+	rq_for_each_bio(bio, rq)
+		bio_for_each_segment(bio_vec, bio, i)
+			/* bio_vec is now current segment */
 
 I/O completion callbacks are per-bio rather than per-segment, so drivers
 that traverse bio chains on completion need to keep that in mind. Drivers

trunk/Documentation/block/ioprio.txt

@@ -86,15 +86,8 @@ extern int sys_ioprio_get(int, int);
 #error "Unsupported arch"
 #endif
 
-static inline int ioprio_set(int which, int who, int ioprio)
-{
-	return syscall(__NR_ioprio_set, which, who, ioprio);
-}
-
-static inline int ioprio_get(int which, int who)
-{
-	return syscall(__NR_ioprio_get, which, who);
-}
+_syscall3(int, ioprio_set, int, which, int, who, int, ioprio);
+_syscall2(int, ioprio_get, int, which, int, who);
 
 enum {
 	IOPRIO_CLASS_NONE,