diff options
105 files changed, 7296 insertions, 2321 deletions
diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss b/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss index 4f29e5f1ebfa..f5bb0a3bb8c0 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss +++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss @@ -59,3 +59,15 @@ Kernel Version: 2.6.31 Contact: iss_storagedev@hp.com Description: Displays the usage count (number of opens) of logical drive Y of controller X. + +Where: /sys/bus/pci/devices/<dev>/ccissX/resettable +Date: February 2011 +Kernel Version: 2.6.38 +Contact: iss_storagedev@hp.com +Description: Value of 1 indicates the controller can honor the reset_devices + kernel parameter. Value of 0 indicates reset_devices cannot be + honored. This is to allow, for example, kexec tools to be able + to warn the user if they designate an unresettable device as + a dump device, as kdump requires resetting the device in order + to work reliably. + diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 2deb069aedf1..8436b018c289 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -55,7 +55,6 @@ mandocs: $(MAN) build_images = mkdir -p $(objtree)/Documentation/DocBook/media/ && \ cp $(srctree)/Documentation/DocBook/dvb/*.png \ $(srctree)/Documentation/DocBook/v4l/*.gif \ - $(srctree)/Documentation/DocBook/v4l/*.png \ $(objtree)/Documentation/DocBook/media/ xmldoclinks: diff --git a/Documentation/DocBook/rapidio.tmpl b/Documentation/DocBook/rapidio.tmpl index 54eb26b57372..50479360d845 100644 --- a/Documentation/DocBook/rapidio.tmpl +++ b/Documentation/DocBook/rapidio.tmpl @@ -133,7 +133,6 @@ !Idrivers/rapidio/rio-sysfs.c </sect1> <sect1 id="PPC32_support"><title>PPC32 support</title> -!Earch/powerpc/sysdev/fsl_rio.c !Iarch/powerpc/sysdev/fsl_rio.c </sect1> </chapter> diff --git a/Documentation/development-process/1.Intro b/Documentation/development-process/1.Intro index 8cc2cba2b10d..9b614480aa84 100644 --- a/Documentation/development-process/1.Intro +++ b/Documentation/development-process/1.Intro @@ -56,13 +56,13 @@ information on kernel development. 1.2: WHAT THIS DOCUMENT IS ABOUT -The Linux kernel, at over 6 million lines of code and well over 1000 active -contributors, is one of the largest and most active free software projects -in existence. Since its humble beginning in 1991, this kernel has evolved -into a best-of-breed operating system component which runs on pocket-sized -digital music players, desktop PCs, the largest supercomputers in -existence, and all types of systems in between. It is a robust, efficient, -and scalable solution for almost any situation. +The Linux kernel, at over 8 million lines of code and well over 1000 +contributors to each release, is one of the largest and most active free +software projects in existence. Since its humble beginning in 1991, this +kernel has evolved into a best-of-breed operating system component which +runs on pocket-sized digital music players, desktop PCs, the largest +supercomputers in existence, and all types of systems in between. It is a +robust, efficient, and scalable solution for almost any situation. With the growth of Linux has come an increase in the number of developers (and companies) wishing to participate in its development. Hardware @@ -115,7 +115,7 @@ This document was written by Jonathan Corbet, corbet@lwn.net. It has been improved by comments from Johannes Berg, James Berry, Alex Chiang, Roland Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata, and -Jochen Voß. +Jochen Voß. This work was supported by the Linux Foundation; thanks especially to Amanda McPherson, who saw the value of this effort and made it all happen. @@ -221,7 +221,7 @@ include: - Everything that was said above about code review applies doubly to closed-source code. Since this code is not available at all, it cannot have been reviewed by the community and will, beyond doubt, have serious - problems. + problems. Makers of embedded systems, in particular, may be tempted to disregard much of what has been said in this section in the belief that they are shipping diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process index 911a45186340..4823577c6509 100644 --- a/Documentation/development-process/2.Process +++ b/Documentation/development-process/2.Process @@ -14,16 +14,15 @@ The kernel developers use a loosely time-based release process, with a new major kernel release happening every two or three months. The recent release history looks like this: - 2.6.26 July 13, 2008 - 2.6.25 April 16, 2008 - 2.6.24 January 24, 2008 - 2.6.23 October 9, 2007 - 2.6.22 July 8, 2007 - 2.6.21 April 25, 2007 - 2.6.20 February 4, 2007 + 2.6.38 March 14, 2011 + 2.6.37 January 4, 2011 + 2.6.36 October 20, 2010 + 2.6.35 August 1, 2010 + 2.6.34 May 15, 2010 + 2.6.33 February 24, 2010 Every 2.6.x release is a major kernel release with new features, internal -API changes, and more. A typical 2.6 release can contain over 10,000 +API changes, and more. A typical 2.6 release can contain nearly 10,000 changesets with changes to several hundred thousand lines of code. 2.6 is thus the leading edge of Linux kernel development; the kernel uses a rolling development model which is continually integrating major changes. @@ -42,13 +41,13 @@ merge window do not come out of thin air; they have been collected, tested, and staged ahead of time. How that process works will be described in detail later on). -The merge window lasts for two weeks. At the end of this time, Linus -Torvalds will declare that the window is closed and release the first of -the "rc" kernels. For the kernel which is destined to be 2.6.26, for -example, the release which happens at the end of the merge window will be -called 2.6.26-rc1. The -rc1 release is the signal that the time to merge -new features has passed, and that the time to stabilize the next kernel has -begun. +The merge window lasts for approximately two weeks. At the end of this +time, Linus Torvalds will declare that the window is closed and release the +first of the "rc" kernels. For the kernel which is destined to be 2.6.40, +for example, the release which happens at the end of the merge window will +be called 2.6.40-rc1. The -rc1 release is the signal that the time to +merge new features has passed, and that the time to stabilize the next +kernel has begun. Over the next six to ten weeks, only patches which fix problems should be submitted to the mainline. On occasion a more significant change will be @@ -66,20 +65,19 @@ will get up to somewhere between -rc6 and -rc9 before the kernel is considered to be sufficiently stable and the final 2.6.x release is made. At that point the whole process starts over again. -As an example, here is how the 2.6.25 development cycle went (all dates in -2008): - - January 24 2.6.24 stable release - February 10 2.6.25-rc1, merge window closes - February 15 2.6.25-rc2 - February 24 2.6.25-rc3 - March 4 2.6.25-rc4 - March 9 2.6.25-rc5 - March 16 2.6.25-rc6 - March 25 2.6.25-rc7 - April 1 2.6.25-rc8 - April 11 2.6.25-rc9 - April 16 2.6.25 stable release +As an example, here is how the 2.6.38 development cycle went (all dates in +2011): + + January 4 2.6.37 stable release + January 18 2.6.38-rc1, merge window closes + January 21 2.6.38-rc2 + February 1 2.6.38-rc3 + February 7 2.6.38 |