Skip to content

Commit

Permalink
Merge branch 'master' into for-next
Browse files Browse the repository at this point in the history 
Conflicts:
	MAINTAINERS
	arch/arm/mach-omap2/pm24xx.c
	drivers/scsi/bfa/bfa_fcpim.c

Needed to update to apply fixes for which the old branch was too
outdated.
  • Loading branch information
Jiri Kosina committed Dec 22, 2010
2 parents c0d8768 + 90a8a73 commit 4b7bd36
Show file tree
Hide file tree
Showing 2,029 changed files with 37,852 additions and 20,361 deletions.
22 changes: 22 additions & 0 deletions Documentation/ABI/obsolete/proc-pid-oom_adj
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
What: /proc/<pid>/oom_adj
When: August 2012
Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's
badness heuristic used to determine which task to kill when the kernel
is out of memory.

The badness heuristic has since been rewritten since the introduction of
this tunable such that its meaning is deprecated. The value was
implemented as a bitshift on a score generated by the badness()
function that did not have any precise units of measure. With the
rewrite, the score is given as a proportion of available memory to the
task allocating pages, so using a bitshift which grows the score
exponentially is, thus, impossible to tune with fine granularity.

A much more powerful interface, /proc/<pid>/oom_score_adj, was
introduced with the oom killer rewrite that allows users to increase or
decrease the badness() score linearly. This interface will replace
/proc/<pid>/oom_adj.

A warning will be emitted to the kernel log if an application uses this
deprecated interface. After it is printed once, future warnings will be
suppressed until the kernel is rebooted.
83 changes: 83 additions & 0 deletions Documentation/ABI/testing/sysfs-bus-rbd
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
What: /sys/bus/rbd/
Date: November 2010
Contact: Yehuda Sadeh <[email protected]>,
Sage Weil <[email protected]>
Description:

Being used for adding and removing rbd block devices.

Usage: <mon ip addr> <options> <pool name> <rbd image name> [snap name]

$ echo "192.168.0.1 name=admin rbd foo" > /sys/bus/rbd/add

The snapshot name can be "-" or omitted to map the image read/write. A <dev-id>
will be assigned for any registered block device. If snapshot is used, it will
be mapped read-only.

Removal of a device:

$ echo <dev-id> > /sys/bus/rbd/remove

Entries under /sys/bus/rbd/devices/<dev-id>/
--------------------------------------------

client_id

The ceph unique client id that was assigned for this specific session.

major

The block device major number.

name

The name of the rbd image.

pool

The pool where this rbd image resides. The pool-name pair is unique
per rados system.

size

The size (in bytes) of the mapped block device.

refresh

Writing to this file will reread the image header data and set
all relevant datastructures accordingly.

current_snap

The current snapshot for which the device is mapped.

create_snap

Create a snapshot:

$ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_create

rollback_snap

Rolls back data to the specified snapshot. This goes over the entire
list of rados blocks and sends a rollback command to each.

$ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_rollback

snap_*

A directory per each snapshot


Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
-------------------------------------------------------------

id

The rados internal snapshot id assigned for this snapshot

size

The size of the image when this snapshot was taken.


16 changes: 15 additions & 1 deletion Documentation/ABI/testing/sysfs-platform-asus-laptop
View file
Original file line number Diff line number Diff line change
Expand Up @@ -47,6 +47,20 @@ Date: January 2007
KernelVersion: 2.6.20
Contact: "Corentin Chary" <[email protected]>
Description:
Control the bluetooth device. 1 means on, 0 means off.
Control the wlan device. 1 means on, 0 means off.
This may control the led, the device or both.
Users: Lapsus

What: /sys/devices/platform/asus_laptop/wimax
Date: October 2010
KernelVersion: 2.6.37
Contact: "Corentin Chary" <[email protected]>
Description:
Control the wimax device. 1 means on, 0 means off.

What: /sys/devices/platform/asus_laptop/wwan
Date: October 2010
KernelVersion: 2.6.37
Contact: "Corentin Chary" <[email protected]>
Description:
Control the wwan (3G) device. 1 means on, 0 means off.
10 changes: 10 additions & 0 deletions Documentation/ABI/testing/sysfs-platform-eeepc-wmi
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
What: /sys/devices/platform/eeepc-wmi/cpufv
Date: Oct 2010
KernelVersion: 2.6.37
Contact: "Corentin Chary" <[email protected]>
Description:
Change CPU clock configuration (write-only).
There are three available clock configuration:
* 0 -> Super Performance Mode
* 1 -> High Performance Mode
* 2 -> Power Saving Mode
4 changes: 0 additions & 4 deletions Documentation/DocBook/sh.tmpl
View file
Original file line number Diff line number Diff line change
Expand Up @@ -79,10 +79,6 @@
</sect2>
</sect1>
</chapter>
<chapter id="clk">
<title>Clock Framework Extensions</title>
!Iinclude/linux/sh_clk.h
</chapter>
<chapter id="mach">
<title>Machine Specific Interfaces</title>
<sect1 id="dreamcast">
Expand Down
6 changes: 3 additions & 3 deletions Documentation/DocBook/uio-howto.tmpl
View file
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@
</orgname>

<address>
<email>hjk@linutronix.de</email>
<email>hjk@hansjkoch.de</email>
</address>
</affiliation>
</author>
Expand Down Expand Up @@ -114,7 +114,7 @@ GPL version 2.

<para>If you know of any translations for this document, or you are
interested in translating it, please email me
<email>hjk@linutronix.de</email>.
<email>hjk@hansjkoch.de</email>.
</para>
</sect1>

Expand Down Expand Up @@ -171,7 +171,7 @@ interested in translating it, please email me
<title>Feedback</title>
<para>Find something wrong with this document? (Or perhaps something
right?) I would love to hear from you. Please email me at
<email>hjk@linutronix.de</email>.</para>
<email>hjk@hansjkoch.de</email>.</para>
</sect1>
</chapter>

Expand Down
7 changes: 4 additions & 3 deletions Documentation/arm/OMAP/DSS
View file
Original file line number Diff line number Diff line change
Expand Up @@ -255,9 +255,10 @@ framebuffer parameters.
Kernel boot arguments
---------------------

vram=<size>
- Amount of total VRAM to preallocate. For example, "10M". omapfb
allocates memory for framebuffers from VRAM.
vram=<size>[,<physaddr>]
- Amount of total VRAM to preallocate and optionally a physical start
memory address. For example, "10M". omapfb allocates memory for
framebuffers from VRAM.

omapfb.mode=<display>:<mode>[,...]
- Default video mode for specified displays. For example,
Expand Down
8 changes: 4 additions & 4 deletions Documentation/block/switching-sched.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -16,7 +16,7 @@ you can do so by typing:
As of the Linux 2.6.10 kernel, it is now possible to change the
IO scheduler for a given block device on the fly (thus making it possible,
for instance, to set the CFQ scheduler for the system default, but
set a specific device to use the anticipatory or noop schedulers - which
set a specific device to use the deadline or noop schedulers - which
can improve that device's throughput).

To set a specific scheduler, simply do this:
Expand All @@ -31,7 +31,7 @@ a "cat /sys/block/DEV/queue/scheduler" - the list of valid names
will be displayed, with the currently selected scheduler in brackets:

# cat /sys/block/hda/queue/scheduler
noop anticipatory deadline [cfq]
# echo anticipatory > /sys/block/hda/queue/scheduler
noop deadline [cfq]
# echo deadline > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler
noop [anticipatory] deadline cfq
noop [deadline] cfq
33 changes: 23 additions & 10 deletions Documentation/development-process/2.Process
View file
Original file line number Diff line number Diff line change
Expand Up @@ -154,7 +154,7 @@ The stages that a patch goes through are, generally:
inclusion, it should be accepted by a relevant subsystem maintainer -
though this acceptance is not a guarantee that the patch will make it
all the way to the mainline. The patch will show up in the maintainer's
subsystem tree and into the staging trees (described below). When the
subsystem tree and into the -next trees (described below). When the
process works, this step leads to more extensive review of the patch and
the discovery of any problems resulting from the integration of this
patch with work being done by others.
Expand Down Expand Up @@ -236,7 +236,7 @@ finding the right maintainer. Sending patches directly to Linus is not
normally the right way to go.


2.4: STAGING TREES
2.4: NEXT TREES

The chain of subsystem trees guides the flow of patches into the kernel,
but it also raises an interesting question: what if somebody wants to look
Expand All @@ -250,7 +250,7 @@ changes land in the mainline kernel. One could pull changes from all of
the interesting subsystem trees, but that would be a big and error-prone
job.

The answer comes in the form of staging trees, where subsystem trees are
The answer comes in the form of -next trees, where subsystem trees are
collected for testing and review. The older of these trees, maintained by
Andrew Morton, is called "-mm" (for memory management, which is how it got
started). The -mm tree integrates patches from a long list of subsystem
Expand All @@ -275,7 +275,7 @@ directory at:
Use of the MMOTM tree is likely to be a frustrating experience, though;
there is a definite chance that it will not even compile.

The other staging tree, started more recently, is linux-next, maintained by
The other -next tree, started more recently, is linux-next, maintained by
Stephen Rothwell. The linux-next tree is, by design, a snapshot of what
the mainline is expected to look like after the next merge window closes.
Linux-next trees are announced on the linux-kernel and linux-next mailing
Expand Down Expand Up @@ -303,12 +303,25 @@ volatility of linux-next tends to make it a difficult development target.
See http://lwn.net/Articles/289013/ for more information on this topic, and
stay tuned; much is still in flux where linux-next is involved.

Besides the mmotm and linux-next trees, the kernel source tree now contains
the drivers/staging/ directory and many sub-directories for drivers or
filesystems that are on their way to being added to the kernel tree
proper, but they remain in drivers/staging/ while they still need more
work.

2.4.1: STAGING TREES

The kernel source tree now contains the drivers/staging/ directory, where
many sub-directories for drivers or filesystems that are on their way to
being added to the kernel tree live. They remain in drivers/staging while
they still need more work; once complete, they can be moved into the
kernel proper. This is a way to keep track of drivers that aren't
up to Linux kernel coding or quality standards, but people may want to use
them and track development.

Greg Kroah-Hartman currently (as of 2.6.36) maintains the staging tree.
Drivers that still need work are sent to him, with each driver having
its own subdirectory in drivers/staging/. Along with the driver source
files, a TODO file should be present in the directory as well. The TODO
file lists the pending work that the driver needs for acceptance into
the kernel proper, as well as a list of people that should be Cc'd for any
patches to the driver. Staging drivers that don't currently build should
have their config entries depend upon CONFIG_BROKEN. Once they can
be successfully built without outside patches, CONFIG_BROKEN can be removed.

2.5: TOOLS

Expand Down
Loading

0 comments on commit 4b7bd36

Please sign in to comment.