Merge with git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

D: Fixed the shm swap deallocation at swapoff time (try_to_unuse message)

D: VM hacker

D: Various other kernel hacks

S: Via Cicalini 26

S: Imola 40026

S: Italy

S: Australia

N: Stephen Smalley

E: sds@epoch.ncsc.mil

E: sds@tycho.nsa.gov

D: portions of the Linux Security Module (LSM) framework and security modules

N: Chris Smith

S: England

N: Chris Wright

E: chrisw@osdl.org

E: chrisw@sous-sol.org

D: hacking on LSM framework and security modules.

S: c/o OSDL

S: 12725 SW Millikan Way, Suite 400

S: Beaverton, OR 97005

S: Portland, OR

S: USA

N: Michal Wronski

			Joel Schopp <jschopp@austin.ibm.com>

		ia64/x86_64:

			Ashok Raj <ashok.raj@intel.com>

		s390:

			Heiko Carstens <heiko.carstens@de.ibm.com>

Authors: Ashok Raj <ashok.raj@intel.com>

Lots of feedback: Nathan Lynch <nathanl@austin.ibm.com>,

             maxcpus=2 will only boot 2. You can choose to bring the

             other cpus later online, read FAQ's for more info.

additional_cpus=n	[x86_64 only] use this to limit hotpluggable cpus.

                        This option sets

additional_cpus*=n	Use this to limit hotpluggable cpus. This option sets

  			cpu_possible_map = cpu_present_map + additional_cpus

(*) Option valid only for following architectures

- x86_64, ia64, s390

ia64 and x86_64 use the number of disabled local apics in ACPI tables MADT

to determine the number of potentially hot-pluggable cpus. The implementation

should only rely on this to count the #of cpus, but *MUST* not rely on the

apicid values in those tables for disabled apics. In the event BIOS doesnt

mark such hot-pluggable cpus as disabled entries, one could use this

parameter "additional_cpus=x" to represent those cpus in the cpu_possible_map.

s390 uses the number of cpus it detects at IPL time to also the number of bits

in cpu_possible_map. If it is desired to add additional cpus at a later time

the number should be specified using this option or the possible_cpus option.

possible_cpus=n		[s390 only] use this to set hotpluggable cpus.

			This option sets possible_cpus bits in

			cpu_possible_map. Thus keeping the numbers of bits set

			constant even if the machine gets rebooted.

			This option overrides additional_cpus.

CPU maps and such

-----------------

[More on cpumaps and primitive to manipulate, please check

Copyright (C) 2004 BULL SA.

Written by Simon.Derr@bull.net

Portions Copyright (c) 2004 Silicon Graphics, Inc.

Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.

Modified by Paul Jackson <pj@sgi.com>

Modified by Christoph Lameter <clameter@sgi.com>

CONTENTS:

=========

These subsets, or "soft partitions" must be able to be dynamically

adjusted, as the job mix changes, without impacting other concurrently

executing jobs.

executing jobs. The location of the running jobs pages may also be moved

when the memory locations are changed.

The kernel cpuset patch provides the minimum essential kernel

mechanisms required to efficiently implement such subsets.  It

1.3 How are cpusets implemented ?

---------------------------------

Cpusets provide a Linux kernel (2.6.7 and above) mechanism to constrain

which CPUs and Memory Nodes are used by a process or set of processes.

Cpusets provide a Linux kernel mechanism to constrain which CPUs and

Memory Nodes are used by a process or set of processes.

The Linux kernel already has a pair of mechanisms to specify on which

CPUs a task may be scheduled (sched_setaffinity) and on which Memory

If the cpuset flag file 'memory_migrate' is set true, then when

tasks are attached to that cpuset, any pages that task had

allocated to it on nodes in its previous cpuset are migrated

to the tasks new cpuset.  Depending on the implementation,

this migration may either be done by swapping the page out,

so that the next time the page is referenced, it will be paged

into the tasks new cpuset, usually on the node where it was

referenced, or this migration may be done by directly copying

the pages from the tasks previous cpuset to the new cpuset,

where possible to the same node, relative to the new cpuset,

as the node that held the page, relative to the old cpuset.

to the tasks new cpuset. The relative placement of the page within

the cpuset is preserved during these migration operations if possible.

For example if the page was on the second valid node of the prior cpuset

then the page will be placed on the second valid node of the new cpuset.

Also if 'memory_migrate' is set true, then if that cpusets

'mems' file is modified, pages allocated to tasks in that

cpuset, that were on nodes in the previous setting of 'mems',

will be moved to nodes in the new setting of 'mems.'  Again,

depending on the implementation, this might be done by swapping,

or by direct copying.  In either case, pages that were not in

the tasks prior cpuset, or in the cpusets prior 'mems' setting,

will not be moved.

will be moved to nodes in the new setting of 'mems.'

Pages that were not in the tasks prior cpuset, or in the cpusets

prior 'mems' setting, will not be moved.

There is an exception to the above.  If hotplug functionality is used

to remove all the CPUs that are currently assigned to a cpuset,

  # The next line should display '/Charlie'

  cat /proc/self/cpuset

In the case that a change of cpuset includes wanting to move already

allocated memory pages, consider further the work of IWAMOTO

Toshihiro <iwamoto@valinux.co.jp> for page remapping and memory

hotremoval, which can be found at:

  http://people.valinux.co.jp/~iwamoto/mh.html

The integration of cpusets with such memory migration is not yet

available.

In the future, a C library interface to cpusets will likely be

available.  For now, the only way to query or modify cpusets is

via the cpuset file system, using the various cd, mkdir, echo, cat,

If you have problems with this please do ask on the mailing list.

--

Authors: Richard Walker, Jamie Honan, Michael Hunold, Manu Abraham

Authors: Richard Walker,

	 Jamie Honan,

	 Michael Hunold,

	 Manu Abraham,

	 Michael Krufky

When:	January 2007

Why:	Is replaced by pci_register_driver(pci_driver).

Who:	Richard Knutsson <ricknu-0@student.ltu.se> and Greg Kroah-Hartman <gregkh@suse.de>

---------------------------

What:	I2C interface of the it87 driver

When:	January 2007

Why:	The ISA interface is faster and should be always available. The I2C

	probing is also known to cause trouble in at least one case (see

	bug #5889.)

Who:	Jean Delvare <khali@linux-fr.org>

---------------------------

What:	mount/umount uevents

When:	February 2007

Why:	These events are not correct, and do not properly let userspace know

	when a file system has been mounted or unmounted.  Userspace should

	poll the /proc/mounts file instead to detect this properly.

Who:	Greg Kroah-Hartman <gregkh@suse.de>

---------------------------

What:	Support for NEC DDB5074 and DDB5476 evaluation boards.

When:	June 2006

Why:	Board specific code doesn't build anymore since ~2.6.0 and no

	users have complained indicating there is no more need for these

	boards.  This should really be considered a last call.

Who:	Ralf Baechle <ralf@linux-mips.org>