Merge branch 'linus' into tracing/ftrace

Documentation/DocBook/Makefile

@@ -136,7 +136,7 @@ quiet_cmd_db2ps = PS      $@
 %.ps : %.xml
 	$(call cmd,db2ps)
 
-quiet_cmd_db2pdf = PDF      $@
+quiet_cmd_db2pdf = PDF     $@
       cmd_db2pdf = $(subst TYPE,pdf, $($(PDF_METHOD)template))
 %.pdf : %.xml
 	$(call cmd,db2pdf)
@@ -148,7 +148,7 @@ build_main_index = rm -rf $(main_idx) && \
 		   echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \
 		   cat $(HTML) >> $(main_idx)
 
-quiet_cmd_db2html = HTML   $@
+quiet_cmd_db2html = HTML    $@
       cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
 		echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
         $(patsubst %.html,%,$(notdir $@))</a><p>' > $@

Documentation/DocBook/deviceiobook.tmpl

@@ -24,7 +24,7 @@
     <surname>Cox</surname>
     <affiliation>
      <address>
-      <email>alan@redhat.com</email>
+      <email>alan@lxorguk.ukuu.org.uk</email>
      </address>
     </affiliation>
    </author>

Documentation/DocBook/mcabook.tmpl

@@ -12,7 +12,7 @@
     <surname>Cox</surname>
     <affiliation>
      <address>
-      <email>alan@redhat.com</email>
+      <email>alan@lxorguk.ukuu.org.uk</email>
      </address>
     </affiliation>
    </author>

Documentation/DocBook/wanbook.tmpl

@@ -12,7 +12,7 @@
     <surname>Cox</surname>
     <affiliation>
      <address>
-      <email>alan@redhat.com</email>
+      <email>alan@lxorguk.ukuu.org.uk</email>
      </address>
     </affiliation>
    </author>

Documentation/DocBook/z8530book.tmpl

@@ -12,7 +12,7 @@
     <surname>Cox</surname>
     <affiliation>
      <address>
-      <email>alan@redhat.com</email>
+      <email>alan@lxorguk.ukuu.org.uk</email>
      </address>
     </affiliation>
    </author>

Documentation/ManagementStyle

@@ -17,7 +17,7 @@ companies.  If you sign purchase orders or you have any clue about the
 budget of your group, you're almost certainly not a kernel manager. 
 These suggestions may or may not apply to you. 
 
-First off, I'd suggest buying "Seven Habits of Highly Successful
+First off, I'd suggest buying "Seven Habits of Highly Effective
 People", and NOT read it.  Burn it, it's a great symbolic gesture. 
 
 (*) This document does so not so much by answering the question, but by

Documentation/accounting/.gitignore

@@ -0,0 +1 @@
+getdelays

Documentation/auxdisplay/.gitignore

@@ -0,0 +1 @@
+cfag12864b-example

Documentation/connector/.gitignore

@@ -0,0 +1 @@
+ucon

Documentation/filesystems/Locking

@@ -161,8 +161,12 @@ prototypes:
 	int (*set_page_dirty)(struct page *page);
 	int (*readpages)(struct file *filp, struct address_space *mapping,
 			struct list_head *pages, unsigned nr_pages);
-	int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);
-	int (*commit_write)(struct file *, struct page *, unsigned, unsigned);
+	int (*write_begin)(struct file *, struct address_space *mapping,
+				loff_t pos, unsigned len, unsigned flags,
+				struct page **pagep, void **fsdata);
+	int (*write_end)(struct file *, struct address_space *mapping,
+				loff_t pos, unsigned len, unsigned copied,
+				struct page *page, void *fsdata);
 	sector_t (*bmap)(struct address_space *, sector_t);
 	int (*invalidatepage) (struct page *, unsigned long);
 	int (*releasepage) (struct page *, int);
@@ -180,8 +184,6 @@ sync_page:		no	maybe
 writepages:		no
 set_page_dirty		no	no
 readpages:		no
-prepare_write:		no	yes			yes
-commit_write:		no	yes			yes
 write_begin:		no	locks the page		yes
 write_end:		no	yes, unlocks		yes
 perform_write:		no	n/a			yes
@@ -191,7 +193,7 @@ releasepage:		no	yes
 direct_IO:		no
 launder_page:		no	yes
 
-	->prepare_write(), ->commit_write(), ->sync_page() and ->readpage()
+	->write_begin(), ->write_end(), ->sync_page() and ->readpage()
 may be called from the request handler (/dev/loop).
 
 	->readpage() unlocks the page, either synchronously or via I/O

Documentation/filesystems/vfs.txt

@@ -492,7 +492,7 @@ written-back to storage typically in whole pages, however the
 address_space has finer control of write sizes.
 
 The read process essentially only requires 'readpage'.  The write
-process is more complicated and uses prepare_write/commit_write or
+process is more complicated and uses write_begin/write_end or
 set_page_dirty to write data into the address_space, and writepage,
 sync_page, and writepages to writeback data to storage.
 
@@ -521,8 +521,6 @@ struct address_space_operations {
 	int (*set_page_dirty)(struct page *page);
 	int (*readpages)(struct file *filp, struct address_space *mapping,
 			struct list_head *pages, unsigned nr_pages);
-	int (*prepare_write)(struct file *, struct page *, unsigned, unsigned);
-	int (*commit_write)(struct file *, struct page *, unsigned, unsigned);
 	int (*write_begin)(struct file *, struct address_space *mapping,
 				loff_t pos, unsigned len, unsigned flags,
 				struct page **pagep, void **fsdata);
@@ -598,37 +596,7 @@ struct address_space_operations {
 	readpages is only used for read-ahead, so read errors are
   	ignored.  If anything goes wrong, feel free to give up.
 
-  prepare_write: called by the generic write path in VM to set up a write
-  	request for a page.  This indicates to the address space that
-  	the given range of bytes is about to be written.  The
-  	address_space should check that the write will be able to
-  	complete, by allocating space if necessary and doing any other
-  	internal housekeeping.  If the write will update parts of
-  	any basic-blocks on storage, then those blocks should be
-  	pre-read (if they haven't been read already) so that the
-  	updated blocks can be written out properly.
-	The page will be locked.
-
-	Note: the page _must not_ be marked uptodate in this function
-	(or anywhere else) unless it actually is uptodate right now. As
-	soon as a page is marked uptodate, it is possible for a concurrent
-	read(2) to copy it to userspace.
-
-  commit_write: If prepare_write succeeds, new data will be copied
-        into the page and then commit_write will be called.  It will
-        typically update the size of the file (if appropriate) and
-        mark the inode as dirty, and do any other related housekeeping
-        operations.  It should avoid returning an error if possible -
-        errors should have been handled by prepare_write.
-
-  write_begin: This is intended as a replacement for prepare_write. The
-	key differences being that:
-		- it returns a locked page (in *pagep) rather than being
-		  given a pre locked page;
-		- it must be able to cope with short writes (where the
-		  length passed to write_begin is greater than the number
-		  of bytes copied into the page).
-
+  write_begin:
 	Called by the generic buffered write code to ask the filesystem to
 	prepare to write len bytes at the given offset in the file. The
 	address_space should check that the write will be able to complete,
@@ -640,6 +608,9 @@ struct address_space_operations {
         The filesystem must return the locked pagecache page for the specified
 	offset, in *pagep, for the caller to write into.
 
+	It must be able to cope with short writes (where the length passed to
+	write_begin is greater than the number of bytes copied into the page).
+
 	flags is a field for AOP_FLAG_xxx flags, described in
 	include/linux/fs.h.
 

Documentation/i2c/busses/i2c-sis96x

@@ -42,7 +42,7 @@ I suspect that this driver could be made to work for the following SiS
 chipsets as well: 635, and 635T. If anyone owns a board with those chips
 AND is willing to risk crashing & burning an otherwise well-behaved kernel
 in the name of progress... please contact me at <mhoffman@lightlink.com> or
-via the project's mailing list: <i2c@lm-sensors.org>.  Please send bug
+via the linux-i2c mailing list: <linux-i2c@vger.kernel.org>.  Please send bug
 reports and/or success stories as well.
 
 

Documentation/ia64/.gitignore

@@ -0,0 +1 @@
+aliasing-test

Documentation/isdn/CREDITS

@@ -5,7 +5,7 @@ I want to thank all who contributed to this project and especially to:
 Thomas Bogendörfer (tsbogend@bigbug.franken.de)
   Tester, lots of bugfixes and hints.
 
-Alan Cox (alan@redhat.com)
+Alan Cox (alan@lxorguk.ukuu.org.uk)
   For help getting into standard-kernel.
 
 Henner Eisen (eis@baty.hanse.de)

Documentation/ja_JP/HOWTO

@@ -11,14 +11,14 @@ for non English (read: Japanese) speakers and is not intended as a
 fork. So if you have any comments or updates for this file, please try
 to update the original English file first.
 
-Last Updated: 2008/08/21
+Last Updated: 2008/10/24
 ==================================
 これは、
-linux-2.6.27/Documentation/HOWTO
+linux-2.6.28/Documentation/HOWTO
 の和訳です。
 
 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
-翻訳日： 2008/8/5
+翻訳日： 2008/10/24
 翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
 校正者： 松倉さん <nbh--mats at nifty dot com>
          小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
@@ -110,8 +110,8 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
 新しいドキュメントファイルも追加することを勧めます。
 カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの
 変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報
-をマニュアルページのメンテナ mtk.manpages@gmail.com に送ることを勧めま
-す。
+をマニュアルページのメンテナ mtk.manpages@gmail.com に送り、CC を
+linux-api@ver.kernel.org に送ることを勧めます。
 
 以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で
 す-
@@ -149,7 +149,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
      この他にパッチを作る方法についてのよくできた記述は-
 
 	"The Perfect Patch"
-		http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
+		http://userweb.kernel.org/~akpm/stuff/tpp.txt
 	"Linux kernel patch submission format"
 		http://linux.yyz.us/patch-format.html
 
@@ -664,7 +664,7 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を
 これについて全てがどのようにあるべきかについての詳細は、以下のドキュメ
 ントの ChangeLog セクションを見てください-
   "The Perfect Patch"
-      http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
+      http://userweb.kernel.org/~akpm/stuff/tpp.txt
 
 これらのどれもが、時にはとても困難です。これらの慣例を完璧に実施するに
 は数年かかるかもしれません。これは継続的な改善のプロセスであり、そのた

Documentation/networking/.gitignore

@@ -0,0 +1 @@
+ifenslave

Documentation/networking/dmfe.txt

@@ -60,6 +60,6 @@ Tobias Ringstrom <tori@unhappy.mine.nu> : Current Maintainer
 Contributors:
 
 Marcelo Tosatti <marcelo@conectiva.com.br>
-Alan Cox <alan@redhat.com>
+Alan Cox <alan@lxorguk.ukuu.org.uk>
 Jeff Garzik <jgarzik@pobox.com>
 Vojtech Pavlik <vojtech@suse.cz>

Documentation/pcmcia/.gitignore

@@ -0,0 +1 @@
+crc32hash

Documentation/scheduler/sched-design-CFS.txt

@@ -92,7 +92,7 @@ other HZ detail.  Thus the CFS scheduler has no notion of "timeslices" in the
 way the previous scheduler had, and has no heuristics whatsoever.  There is
 only one central tunable (you have to switch on CONFIG_SCHED_DEBUG):
 
-   /proc/sys/kernel/sched_granularity_ns
+   /proc/sys/kernel/sched_min_granularity_ns
 
 which can be used to tune the scheduler from "desktop" (i.e., low latencies) to
 "server" (i.e., good batching) workloads.  It defaults to a setting suitable

Documentation/scsi/aacraid.txt

@@ -128,7 +128,7 @@ Supported Cards/Chipsets
 
 People
 -------------------------
-Alan Cox <alan@redhat.com>
+Alan Cox <alan@lxorguk.ukuu.org.uk>
 Christoph Hellwig <hch@infradead.org>	(updates for new-style PCI probing and SCSI host registration,
 					 small cleanups/fixes)
 Matt Domsch <matt_domsch@dell.com>	(revision ioctl, adapter messages)

Documentation/spi/.gitignore

@@ -0,0 +1,2 @@
+spidev_fdx
+spidev_test

Documentation/stable_kernel_rules.txt

@@ -12,6 +12,7 @@ Rules on what kind of patches are accepted, and which ones are not, into the
    marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
    security issue, or some "oh, that's not good" issue.  In short, something
    critical.
+ - New device IDs and quirks are also accepted.
  - No "theoretical race condition" issues, unless an explanation of how the
    race can be exploited is also provided.
  - It cannot contain any "trivial" fixes in it (spelling changes,

Documentation/sysctl/kernel.txt

@@ -363,11 +363,21 @@ tainted:
 Non-zero if the kernel has been tainted.  Numeric values, which
 can be ORed together:
 
-  1 - A module with a non-GPL license has been loaded, this
-      includes modules with no license.
-      Set by modutils >= 2.4.9 and module-init-tools.
-  2 - A module was force loaded by insmod -f.
-      Set by modutils >= 2.4.9 and module-init-tools.
-  4 - Unsafe SMP processors: SMP with CPUs not designed for SMP.
- 64 - A module from drivers/staging was loaded.
+   1 - A module with a non-GPL license has been loaded, this
+       includes modules with no license.
+       Set by modutils >= 2.4.9 and module-init-tools.
+   2 - A module was force loaded by insmod -f.
+       Set by modutils >= 2.4.9 and module-init-tools.
+   4 - Unsafe SMP processors: SMP with CPUs not designed for SMP.
+   8 - A module was forcibly unloaded from the system by rmmod -f.
+  16 - A hardware machine check error occurred on the system.
+  32 - A bad page was discovered on the system.
+  64 - The user has asked that the system be marked "tainted".  This
+       could be because they are running software that directly modifies
+       the hardware, or for other reasons.
+ 128 - The system has died.
+ 256 - The ACPI DSDT has been overridden with one supplied by the user
+        instead of using the one provided by the hardware.
+ 512 - A kernel warning has occurred.
+1024 - A module from drivers/staging was loaded.
 

Documentation/video4linux/.gitignore

@@ -0,0 +1 @@
+v4lgrab

Documentation/video4linux/bttv/CONTRIBUTORS

@@ -3,7 +3,7 @@ Contributors to bttv:
 Michael Chu <mmchu@pobox.com>
   AverMedia fix and more flexible card recognition
 
-Alan Cox <alan@redhat.com>
+Alan Cox <alan@lxorguk.ukuu.org.uk>
   Video4Linux interface and 2.1.x kernel adaptation
 
 Chris Kleitsch

Documentation/vm/.gitignore

@@ -0,0 +1 @@
+slabinfo

Documentation/watchdog/src/.gitignore

@@ -0,0 +1,2 @@
+watchdog-simple
+watchdog-test