Merge commit 'v2.6.38-rc3' into next
This commit is contained in:
Dmitry Torokhov
commit
a1f3d4bba8
2
.mailmap
2
.mailmap
@ -23,6 +23,7 @@ Andy Adamson <andros@citi.umich.edu>
|
||||
Arnaud Patard <arnaud.patard@rtp-net.org>
|
||||
Arnd Bergmann <arnd@arndb.de>
|
||||
Axel Dyks <xl@xlsigned.net>
|
||||
Axel Lin <axel.lin@gmail.com>
|
||||
Ben Gardner <bgardner@wabtec.com>
|
||||
Ben M Cahill <ben.m.cahill@intel.com>
|
||||
Björn Steinbrink <B.Steinbrink@gmx.de>
|
||||
@ -105,3 +106,4 @@ Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
|
||||
Uwe Kleine-König <ukl@pengutronix.de>
|
||||
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
|
||||
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
|
||||
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
|
||||
|
||||
6
CREDITS
6
CREDITS
@ -2365,8 +2365,6 @@ E: acme@redhat.com
|
||||
W: http://oops.ghostprotocols.net:81/blog/
|
||||
P: 1024D/9224DF01 D5DF E3BB E3C8 BCBB F8AD 841A B6AB 4681 9224 DF01
|
||||
D: IPX, LLC, DCCP, cyc2x, wl3501_cs, net/ hacks
|
||||
S: R. Brasílio Itiberê, 4270/1010 - Água Verde
|
||||
S: 80240-060 - Curitiba - Paraná
|
||||
S: Brazil
|
||||
|
||||
N: Karsten Merker
|
||||
@ -2813,8 +2811,8 @@ D: CDROM driver "sonycd535" (Sony CDU-535/531)
|
||||
N: Stelian Pop
|
||||
E: stelian@popies.net
|
||||
P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0 D3F7 7185 9E7A EDBB 6147
|
||||
D: sonypi, meye drivers, mct_u232 usb serial hacks
|
||||
S: Paris, France
|
||||
D: random kernel hacks
|
||||
S: Paimpont, France
|
||||
|
||||
N: Pete Popov
|
||||
E: pete_popov@yahoo.com
|
||||
|
||||
22
Documentation/ABI/obsolete/proc-pid-oom_adj
Normal file
22
Documentation/ABI/obsolete/proc-pid-oom_adj
Normal file
@ -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.
|
||||
4
Documentation/ABI/stable/thermal-notification
Normal file
4
Documentation/ABI/stable/thermal-notification
Normal file
@ -0,0 +1,4 @@
|
||||
What: A notification mechanism for thermal related events
|
||||
Description:
|
||||
This interface enables notification for thermal related events.
|
||||
The notification is in the form of a netlink event.
|
||||
83
Documentation/ABI/testing/sysfs-bus-rbd
Normal file
83
Documentation/ABI/testing/sysfs-bus-rbd
Normal file
@ -0,0 +1,83 @@
|
||||
What: /sys/bus/rbd/
|
||||
Date: November 2010
|
||||
Contact: Yehuda Sadeh <yehuda@hq.newdream.net>,
|
||||
Sage Weil <sage@newdream.net>
|
||||
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.
|
||||
|
||||
|
||||
@ -26,3 +26,12 @@ Description:
|
||||
scheduler is chosen. Trigger specific parameters can appear in
|
||||
/sys/class/leds/<led> once a given trigger is selected.
|
||||
|
||||
What: /sys/class/leds/<led>/inverted
|
||||
Date: January 2011
|
||||
KernelVersion: 2.6.38
|
||||
Contact: Richard Purdie <rpurdie@rpsys.net>
|
||||
Description:
|
||||
Invert the LED on/off state. This parameter is specific to
|
||||
gpio and backlight triggers. In case of the backlight trigger,
|
||||
it is usefull when driving a LED which is intended to indicate
|
||||
a device in a standby like state.
|
||||
|
||||
@ -22,6 +22,27 @@ Description:
|
||||
mesh will be fragmented or silently discarded if the
|
||||
packet size exceeds the outgoing interface MTU.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/gw_bandwidth
|
||||
Date: October 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Description:
|
||||
Defines the bandwidth which is propagated by this
|
||||
node if gw_mode was set to 'server'.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/gw_mode
|
||||
Date: October 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Description:
|
||||
Defines the state of the gateway features. Can be
|
||||
either 'off', 'client' or 'server'.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/gw_sel_class
|
||||
Date: October 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
Description:
|
||||
Defines the selection criteria this node will use
|
||||
to choose a gateway if gw_mode was set to 'client'.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/orig_interval
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
@ -29,6 +50,13 @@ Description:
|
||||
Defines the interval in milliseconds in which batman
|
||||
sends its protocol messages.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/hop_penalty
|
||||
Date: Oct 2010
|
||||
Contact: Linus Lüssing <linus.luessing@web.de>
|
||||
Description:
|
||||
Defines the penalty which will be applied to an
|
||||
originator message's tq-field on every hop.
|
||||
|
||||
What: /sys/class/net/<mesh_iface>/mesh/vis_mode
|
||||
Date: May 2010
|
||||
Contact: Marek Lindner <lindner_marek@yahoo.de>
|
||||
@ -1,4 +1,4 @@
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_dpi
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/actual_dpi
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: It is possible to switch the dpi setting of the mouse with the
|
||||
@ -17,13 +17,13 @@ Description: It is possible to switch the dpi setting of the mouse with the
|
||||
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_profile
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/actual_profile
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the number of the actual profile.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/firmware_version
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/firmware_version
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the raw integer version number of the
|
||||
@ -33,7 +33,7 @@ Description: When read, this file returns the raw integer version number of the
|
||||
left. E.g. a returned value of 138 means 1.38
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/profile[1-5]
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
@ -48,7 +48,7 @@ Description: The mouse can store 5 profiles which can be switched by the
|
||||
stored in the profile doesn't need to fit the number of the
|
||||
store.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/settings
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/settings
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the settings stored in the mouse.
|
||||
@ -58,7 +58,7 @@ Description: When read, this file returns the settings stored in the mouse.
|
||||
The data has to be 36 bytes long. The mouse will reject invalid
|
||||
data.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/startup_profile
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/startup_profile
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 1 to 5.
|
||||
@ -67,7 +67,7 @@ Description: The integer value of this attribute ranges from 1 to 5.
|
||||
When written, this file sets the number of the startup profile
|
||||
and the mouse activates this profile immediately.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/tcu
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/tcu
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse has a "Tracking Control Unit" which lets the user
|
||||
@ -78,7 +78,7 @@ Description: The mouse has a "Tracking Control Unit" which lets the user
|
||||
Writing 1 in this file will start the calibration which takes
|
||||
around 6 seconds to complete and activates the TCU.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/weight
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/weight
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can be equipped with one of four supplied weights
|
||||
|
||||
108
Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
Normal file
108
Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
Normal file
@ -0,0 +1,108 @@
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/actual_profile
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the number of the actual profile in
|
||||
range 0-4.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the raw integer version number of the
|
||||
firmware reported by the mouse. Using the integer value eases
|
||||
further usage in other programs. To receive the real version
|
||||
number the decimal point has to be shifted 2 positions to the
|
||||
left. E.g. a returned value of 121 means 1.21
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/macro
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store a macro with max 500 key/button strokes
|
||||
internally.
|
||||
When written, this file lets one set the sequence for a specific
|
||||
button for a specific profile. Button and profile numbers are
|
||||
included in written data. The data has to be 2082 bytes long.
|
||||
This file is writeonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_buttons
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_buttons holds informations about button layout.
|
||||
When written, this file lets one write the respective profile
|
||||
buttons back to the mouse. The data has to be 77 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
This file is writeonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_buttons
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_buttons holds informations about button layout.
|
||||
When read, these files return the respective profile buttons.
|
||||
The returned data is 77 bytes in size.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_settings
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_settings holds informations like resolution, sensitivity
|
||||
and light effects.
|
||||
When written, this file lets one write the respective profile
|
||||
settings back to the mouse. The data has to be 43 bytes long.
|
||||
The mouse will reject invalid data.
|
||||
Which profile to write is determined by the profile number
|
||||
contained in the data.
|
||||
This file is writeonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_settings
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile is split in settings and buttons.
|
||||
profile_settings holds informations like resolution, sensitivity
|
||||
and light effects.
|
||||
When read, these files return the respective profile settings.
|
||||
The returned data is 43 bytes in size.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/sensor
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse has a tracking- and a distance-control-unit. These
|
||||
can be activated/deactivated and the lift-off distance can be
|
||||
set. The data has to be 6 bytes long.
|
||||
This file is writeonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 0-4.
|
||||
When read, this attribute returns the number of the profile
|
||||
that's active when the mouse is powered on.
|
||||
When written, this file sets the number of the startup profile
|
||||
and the mouse activates this profile immediately.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written a calibration process for the tracking control unit
|
||||
can be initiated/cancelled.
|
||||
The data has to be 3 bytes long.
|
||||
This file is writeonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu_image
|
||||
Date: October 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read the mouse returns a 30x30 pixel image of the
|
||||
sampled underground. This works only in the course of a
|
||||
calibration process initiated with tcu.
|
||||
The returned data is 1028 bytes in size.
|
||||
This file is readonly.
|
||||
@ -1,4 +1,4 @@
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_cpi
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_cpi
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: It is possible to switch the cpi setting of the mouse with the
|
||||
@ -14,14 +14,14 @@ Description: It is possible to switch the cpi setting of the mouse with the
|
||||
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_profile
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_profile
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the number of the actual profile in
|
||||
range 0-4.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/firmware_version
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/firmware_version
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the raw integer version number of the
|
||||
@ -31,7 +31,7 @@ Description: When read, this file returns the raw integer version number of the
|
||||
left. E.g. a returned value of 138 means 1.38
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile_settings
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_settings
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
@ -45,7 +45,7 @@ Description: The mouse can store 5 profiles which can be switched by the
|
||||
contained in the data.
|
||||
This file is writeonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]_settings
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_settings
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
@ -56,7 +56,7 @@ Description: The mouse can store 5 profiles which can be switched by the
|
||||
The returned data is 13 bytes in size.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile_buttons
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_buttons
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
@ -69,7 +69,7 @@ Description: The mouse can store 5 profiles which can be switched by the
|
||||
contained in the data.
|
||||
This file is writeonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]_buttons
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_buttons
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
@ -79,7 +79,7 @@ Description: The mouse can store 5 profiles which can be switched by the
|
||||
The returned data is 19 bytes in size.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/startup_profile
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/startup_profile
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 0-4.
|
||||
@ -87,7 +87,7 @@ Description: The integer value of this attribute ranges from 0-4.
|
||||
that's active when the mouse is powered on.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/settings
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/settings
|
||||
Date: August 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the settings stored in the mouse.
|
||||
|
||||
@ -47,6 +47,20 @@ Date: January 2007
|
||||
KernelVersion: 2.6.20
|
||||
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
||||
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" <corentincj@iksaif.net>
|
||||
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" <corentincj@iksaif.net>
|
||||
Description:
|
||||
Control the wwan (3G) device. 1 means on, 0 means off.
|
||||
|
||||
25
Documentation/ABI/testing/sysfs-platform-at91
Normal file
25
Documentation/ABI/testing/sysfs-platform-at91
Normal file
@ -0,0 +1,25 @@
|
||||
What: /sys/devices/platform/at91_can/net/<iface>/mb0_id
|
||||
Date: January 2011
|
||||
KernelVersion: 2.6.38
|
||||
Contact: Marc Kleine-Budde <kernel@pengutronix.de>
|
||||
Description:
|
||||
Value representing the can_id of mailbox 0.
|
||||
|
||||
Default: 0x7ff (standard frame)
|
||||
|
||||
Due to a chip bug (errata 50.2.6.3 & 50.3.5.3 in
|
||||
"AT91SAM9263 Preliminary 6249H-ATARM-27-Jul-09") the
|
||||
contents of mailbox 0 may be send under certain
|
||||
conditions (even if disabled or in rx mode).
|
||||
|
||||
The workaround in the errata suggests not to use the
|
||||
mailbox and load it with an unused identifier.
|
||||
|
||||
In order to use an extended can_id add the
|
||||
CAN_EFF_FLAG (0x80000000U) to the can_id. Example:
|
||||
|
||||
- standard id 0x7ff:
|
||||
echo 0x7ff > /sys/class/net/can0/mb0_id
|
||||
|
||||
- extended id 0x1fffffff:
|
||||
echo 0x9fffffff > /sys/class/net/can0/mb0_id
|
||||
10
Documentation/ABI/testing/sysfs-platform-eeepc-wmi
Normal file
10
Documentation/ABI/testing/sysfs-platform-eeepc-wmi
Normal file
@ -0,0 +1,10 @@
|
||||
What: /sys/devices/platform/eeepc-wmi/cpufv
|
||||
Date: Oct 2010
|
||||
KernelVersion: 2.6.37
|
||||
Contact: "Corentin Chary" <corentincj@iksaif.net>
|
||||
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
|
||||
6
Documentation/ABI/testing/sysfs-platform-ideapad-laptop
Normal file
6
Documentation/ABI/testing/sysfs-platform-ideapad-laptop
Normal file
@ -0,0 +1,6 @@
|
||||
What: /sys/devices/platform/ideapad/camera_power
|
||||
Date: Dec 2010
|
||||
KernelVersion: 2.6.37
|
||||
Contact: "Ike Panhc <ike.pan@canonical.com>"
|
||||
Description:
|
||||
Control the power of camera module. 1 means on, 0 means off.
|
||||
19
Documentation/ABI/testing/sysfs-tty
Normal file
19
Documentation/ABI/testing/sysfs-tty
Normal file
@ -0,0 +1,19 @@
|
||||
What: /sys/class/tty/console/active
|
||||
Date: Nov 2010
|
||||
Contact: Kay Sievers <kay.sievers@vrfy.org>
|
||||
Description:
|
||||
Shows the list of currently configured
|
||||
console devices, like 'tty1 ttyS0'.
|
||||
The last entry in the file is the active
|
||||
device connected to /dev/console.
|
||||
The file supports poll() to detect virtual
|
||||
console switches.
|
||||
|
||||
What: /sys/class/tty/tty0/active
|
||||
Date: Nov 2010
|
||||
Contact: Kay Sievers <kay.sievers@vrfy.org>
|
||||
Description:
|
||||
Shows the currently active virtual console
|
||||
device, like 'tty1'.
|
||||
The file supports poll() to detect virtual
|
||||
console switches.
|
||||
@ -146,6 +146,7 @@
|
||||
!Finclude/net/cfg80211.h cfg80211_rx_mgmt
|
||||
!Finclude/net/cfg80211.h cfg80211_mgmt_tx_status
|
||||
!Finclude/net/cfg80211.h cfg80211_cqm_rssi_notify
|
||||
!Finclude/net/cfg80211.h cfg80211_cqm_pktloss_notify
|
||||
!Finclude/net/cfg80211.h cfg80211_michael_mic_failure
|
||||
</chapter>
|
||||
<chapter>
|
||||
@ -267,10 +268,6 @@
|
||||
!Finclude/net/mac80211.h ieee80211_ops
|
||||
!Finclude/net/mac80211.h ieee80211_alloc_hw
|
||||
!Finclude/net/mac80211.h ieee80211_register_hw
|
||||
!Finclude/net/mac80211.h ieee80211_get_tx_led_name
|
||||
!Finclude/net/mac80211.h ieee80211_get_rx_led_name
|
||||
!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
|
||||
!Finclude/net/mac80211.h ieee80211_get_radio_led_name
|
||||
!Finclude/net/mac80211.h ieee80211_unregister_hw
|
||||
!Finclude/net/mac80211.h ieee80211_free_hw
|
||||
</chapter>
|
||||
@ -332,10 +329,16 @@
|
||||
<title>functions/definitions</title>
|
||||
!Finclude/net/mac80211.h ieee80211_rx_status
|
||||
!Finclude/net/mac80211.h mac80211_rx_flags
|
||||
!Finclude/net/mac80211.h mac80211_tx_control_flags
|
||||
!Finclude/net/mac80211.h mac80211_rate_control_flags
|
||||
!Finclude/net/mac80211.h ieee80211_tx_rate
|
||||
!Finclude/net/mac80211.h ieee80211_tx_info
|
||||
!Finclude/net/mac80211.h ieee80211_tx_info_clear_status
|
||||
!Finclude/net/mac80211.h ieee80211_rx
|
||||
!Finclude/net/mac80211.h ieee80211_rx_ni
|
||||
!Finclude/net/mac80211.h ieee80211_rx_irqsafe
|
||||
!Finclude/net/mac80211.h ieee80211_tx_status
|
||||
!Finclude/net/mac80211.h ieee80211_tx_status_ni
|
||||
!Finclude/net/mac80211.h ieee80211_tx_status_irqsafe
|
||||
!Finclude/net/mac80211.h ieee80211_rts_get
|
||||
!Finclude/net/mac80211.h ieee80211_rts_duration
|
||||
@ -346,6 +349,7 @@
|
||||
!Finclude/net/mac80211.h ieee80211_stop_queue
|
||||
!Finclude/net/mac80211.h ieee80211_wake_queues
|
||||
!Finclude/net/mac80211.h ieee80211_stop_queues
|
||||
!Finclude/net/mac80211.h ieee80211_queue_stopped
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
@ -354,6 +358,13 @@
|
||||
!Pinclude/net/mac80211.h Frame filtering
|
||||
!Finclude/net/mac80211.h ieee80211_filter_flags
|
||||
</chapter>
|
||||
|
||||
<chapter id="workqueue">
|
||||
<title>The mac80211 workqueue</title>
|
||||
!Pinclude/net/mac80211.h mac80211 workqueue
|
||||
!Finclude/net/mac80211.h ieee80211_queue_work
|
||||
!Finclude/net/mac80211.h ieee80211_queue_delayed_work
|
||||
</chapter>
|
||||
</part>
|
||||
|
||||
<part id="advanced">
|
||||
@ -367,6 +378,23 @@
|
||||
</para>
|
||||
</partintro>
|
||||
|
||||
<chapter id="led-support">
|
||||
<title>LED support</title>
|
||||
<para>
|
||||
Mac80211 supports various ways of blinking LEDs. Wherever possible,
|
||||
device LEDs should be exposed as LED class devices and hooked up to
|
||||
the appropriate trigger, which will then be triggered appropriately
|
||||
by mac80211.
|
||||
</para>
|
||||
!Finclude/net/mac80211.h ieee80211_get_tx_led_name
|
||||
!Finclude/net/mac80211.h ieee80211_get_rx_led_name
|
||||
!Finclude/net/mac80211.h ieee80211_get_assoc_led_name
|
||||
!Finclude/net/mac80211.h ieee80211_get_radio_led_name
|
||||
!Finclude/net/mac80211.h ieee80211_tpt_blink
|
||||
!Finclude/net/mac80211.h ieee80211_tpt_led_trigger_flags
|
||||
!Finclude/net/mac80211.h ieee80211_create_tpt_led_trigger
|
||||
</chapter>
|
||||
|
||||
<chapter id="hardware-crypto-offload">
|
||||
<title>Hardware crypto acceleration</title>
|
||||
!Pinclude/net/mac80211.h Hardware crypto acceleration
|
||||
@ -374,6 +402,9 @@
|
||||
!Finclude/net/mac80211.h set_key_cmd
|
||||
!Finclude/net/mac80211.h ieee80211_key_conf
|
||||
!Finclude/net/mac80211.h ieee80211_key_flags
|
||||
!Finclude/net/mac80211.h ieee80211_tkip_key_type
|
||||
!Finclude/net/mac80211.h ieee80211_get_tkip_key
|
||||
!Finclude/net/mac80211.h ieee80211_key_removed
|
||||
</chapter>
|
||||
|
||||
<chapter id="powersave">
|
||||
@ -417,6 +448,18 @@
|
||||
supported by mac80211, add notes about supporting hw crypto
|
||||
with it.
|
||||
</para>
|
||||
!Finclude/net/mac80211.h ieee80211_iterate_active_interfaces
|
||||
!Finclude/net/mac80211.h ieee80211_iterate_active_interfaces_atomic
|
||||
</chapter>
|
||||
|
||||
<chapter id="station-handling">
|
||||
<title>Station handling</title>
|
||||
<para>TODO</para>
|
||||
!Finclude/net/mac80211.h ieee80211_sta
|
||||
!Finclude/net/mac80211.h sta_notify_cmd
|
||||
!Finclude/net/mac80211.h ieee80211_find_sta
|
||||
!Finclude/net/mac80211.h ieee80211_find_sta_by_ifaddr
|
||||
!Finclude/net/mac80211.h ieee80211_sta_block_awake
|
||||
</chapter>
|
||||
|
||||
<chapter id="hardware-scan-offload">
|
||||
@ -424,6 +467,28 @@
|
||||
<para>TBD</para>
|
||||
!Finclude/net/mac80211.h ieee80211_scan_completed
|
||||
</chapter>
|
||||
|
||||
<chapter id="aggregation">
|
||||
<title>Aggregation</title>
|
||||
<sect1>
|
||||
<title>TX A-MPDU aggregation</title>
|
||||
!Pnet/mac80211/agg-tx.c TX A-MPDU aggregation
|
||||
!Cnet/mac80211/agg-tx.c
|
||||
</sect1>
|
||||
<sect1>
|
||||
<title>RX A-MPDU aggregation</title>
|
||||
!Pnet/mac80211/agg-rx.c RX A-MPDU aggregation
|
||||
!Cnet/mac80211/agg-rx.c
|
||||
</sect1>
|
||||
!Finclude/net/mac80211.h ieee80211_ampdu_mlme_action
|
||||
</chapter>
|
||||
|
||||
<chapter id="smps">
|
||||
<title>Spatial Multiplexing Powersave (SMPS)</title>
|
||||
!Pinclude/net/mac80211.h Spatial multiplexing power save
|
||||
!Finclude/net/mac80211.h ieee80211_request_smps
|
||||
!Finclude/net/mac80211.h ieee80211_smps_mode
|
||||
</chapter>
|
||||
</part>
|
||||
|
||||
<part id="rate-control">
|
||||
@ -435,9 +500,16 @@
|
||||
interface and how it relates to mac80211 and drivers.
|
||||
</para>
|
||||
</partintro>
|
||||
<chapter id="dummy">
|
||||
<title>dummy chapter</title>
|
||||
<chapter id="ratecontrol-api">
|
||||
<title>Rate Control API</title>
|
||||
<para>TBD</para>
|
||||
!Finclude/net/mac80211.h ieee80211_start_tx_ba_session
|
||||
!Finclude/net/mac80211.h ieee80211_start_tx_ba_cb_irqsafe
|
||||
!Finclude/net/mac80211.h ieee80211_stop_tx_ba_session
|
||||
!Finclude/net/mac80211.h ieee80211_stop_tx_ba_cb_irqsafe
|
||||
!Finclude/net/mac80211.h rate_control_changed
|
||||
!Finclude/net/mac80211.h ieee80211_tx_rate_control
|
||||
!Finclude/net/mac80211.h rate_control_send_low
|
||||
</chapter>
|
||||
</part>
|
||||
|
||||
@ -485,6 +557,13 @@
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<chapter id="aggregation-internals">
|
||||
<title>Aggregation</title>
|
||||
!Fnet/mac80211/sta_info.h sta_ampdu_mlme
|
||||
!Fnet/mac80211/sta_info.h tid_ampdu_tx
|
||||
!Fnet/mac80211/sta_info.h tid_ampdu_rx
|
||||
</chapter>
|
||||
|
||||
<chapter id="synchronisation">
|
||||
<title>Synchronisation</title>
|
||||
<para>TBD</para>
|
||||
|
||||
@ -217,8 +217,8 @@ X!Isound/sound_firmware.c
|
||||
<chapter id="uart16x50">
|
||||
<title>16x50 UART Driver</title>
|
||||
!Iinclude/linux/serial_core.h
|
||||
!Edrivers/serial/serial_core.c
|
||||
!Edrivers/serial/8250.c
|
||||
!Edrivers/tty/serial/serial_core.c
|
||||
!Edrivers/tty/serial/8250.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="fbdev">
|
||||
|
||||
@ -28,7 +28,7 @@
|
||||
<holder>Convergence GmbH</holder>
|
||||
</copyright>
|
||||
<copyright>
|
||||
<year>2009-2010</year>
|
||||
<year>2009-2011</year>
|
||||
<holder>Mauro Carvalho Chehab</holder>
|
||||
</copyright>
|
||||
|
||||
|
||||
@ -28,7 +28,7 @@
|
||||
<title>LINUX MEDIA INFRASTRUCTURE API</title>
|
||||
|
||||
<copyright>
|
||||
<year>2009-2010</year>
|
||||
<year>2009-2011</year>
|
||||
<holder>LinuxTV Developers</holder>
|
||||
</copyright>
|
||||
|
||||
@ -86,7 +86,7 @@ Foundation. A copy of the license is included in the chapter entitled
|
||||
</author>
|
||||
</authorgroup>
|
||||
<copyright>
|
||||
<year>2009-2010</year>
|
||||
<year>2009-2011</year>
|
||||
<holder>Mauro Carvalho Chehab</holder>
|
||||
</copyright>
|
||||
|
||||
|
||||
@ -250,7 +250,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd)
|
||||
<title>Device ready function</title>
|
||||
<para>
|
||||
If the hardware interface has the ready busy pin of the NAND chip connected to a
|
||||
GPIO or other accesible I/O pin, this function is used to read back the state of the
|
||||
GPIO or other accessible I/O pin, this function is used to read back the state of the
|
||||
pin. The function has no arguments and should return 0, if the device is busy (R/B pin
|
||||
is low) and 1, if the device is ready (R/B pin is high).
|
||||
If the hardware interface does not give access to the ready busy pin, then
|
||||
|
||||
@ -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">
|
||||
|
||||
@ -16,7 +16,7 @@
|
||||
</orgname>
|
||||
|
||||
<address>
|
||||
<email>hjk@linutronix.de</email>
|
||||
<email>hjk@hansjkoch.de</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
@ -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>
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
@ -75,6 +75,7 @@ as follows:</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>RDS datastructures</title>
|
||||
<table frame="none" pgwide="1" id="v4l2-rds-data">
|
||||
<title>struct
|
||||
<structname>v4l2_rds_data</structname></title>
|
||||
@ -129,10 +130,11 @@ as follows:</para>
|
||||
|
||||
<table frame="none" pgwide="1" id="v4l2-rds-block-codes">
|
||||
<title>Block defines</title>
|
||||
<tgroup cols="3">
|
||||
<tgroup cols="4">
|
||||
<colspec colname="c1" colwidth="1*" />
|
||||
<colspec colname="c2" colwidth="1*" />
|
||||
<colspec colname="c3" colwidth="5*" />
|
||||
<colspec colname="c3" colwidth="1*" />
|
||||
<colspec colname="c4" colwidth="5*" />
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>V4L2_RDS_BLOCK_MSK</entry>
|
||||
|
||||
@ -34,8 +34,7 @@
|
||||
<varlistentry>
|
||||
<term><parameter>request</parameter></term>
|
||||
<listitem>
|
||||
<para>V4L2 ioctl request code as defined in the <link
|
||||
linkend="videodev">videodev.h</link> header file, for example
|
||||
<para>V4L2 ioctl request code as defined in the <filename>videodev2.h</filename> header file, for example
|
||||
VIDIOC_QUERYCAP.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -57,7 +56,7 @@ file descriptor. An ioctl <parameter>request</parameter> has encoded
|
||||
in it whether the argument is an input, output or read/write
|
||||
parameter, and the size of the argument <parameter>argp</parameter> in
|
||||
bytes. Macros and defines specifying V4L2 ioctl requests are located
|
||||
in the <link linkend="videodev">videodev.h</link> header file.
|
||||
in the <filename>videodev2.h</filename> header file.
|
||||
Applications should use their own copy, not include the version in the
|
||||
kernel sources on the system they compile on. All V4L2 ioctl requests,
|
||||
their respective function and parameters are specified in <xref
|
||||
|
||||
@ -142,8 +142,8 @@ leftmost pixel of the second row from the top, and so on. The last row
|
||||
has just as many pad bytes after it as the other rows.</para>
|
||||
|
||||
<para>In V4L2 each format has an identifier which looks like
|
||||
<constant>PIX_FMT_XXX</constant>, defined in the <link
|
||||
linkend="videodev">videodev.h</link> header file. These identifiers
|
||||
<constant>PIX_FMT_XXX</constant>, defined in the <filename>videodev2.h</filename>
|
||||
header file. These identifiers
|
||||
represent <link linkend="v4l2-fourcc">four character codes</link>
|
||||
which are also listed below, however they are not the same as those
|
||||
used in the Windows world.</para>
|
||||
|
||||
@ -100,6 +100,7 @@ Remote Controller chapter.</contrib>
|
||||
<year>2008</year>
|
||||
<year>2009</year>
|
||||
<year>2010</year>
|
||||
<year>2011</year>
|
||||
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
|
||||
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
|
||||
</copyright>
|
||||
@ -381,7 +382,7 @@ and discussions on the V4L mailing list.</revremark>
|
||||
</partinfo>
|
||||
|
||||
<title>Video for Linux Two API Specification</title>
|
||||
<subtitle>Revision 2.6.33</subtitle>
|
||||
<subtitle>Revision 2.6.38</subtitle>
|
||||
|
||||
<chapter id="common">
|
||||
&sub-common;
|
||||
|
||||
@ -533,6 +533,33 @@ completion during sending a panic event.
|
||||
Other Pieces
|
||||
------------
|
||||
|
||||
Get the detailed info related with the IPMI device
|
||||
--------------------------------------------------
|
||||
|
||||
Some users need more detailed information about a device, like where
|
||||
the address came from or the raw base device for the IPMI interface.
|
||||
You can use the IPMI smi_watcher to catch the IPMI interfaces as they
|
||||
come or go, and to grab the information, you can use the function
|
||||
ipmi_get_smi_info(), which returns the following structure:
|
||||
|
||||
struct ipmi_smi_info {
|
||||
enum ipmi_addr_src addr_src;
|
||||
struct device *dev;
|
||||
union {
|
||||
struct {
|
||||
void *acpi_handle;
|
||||
} acpi_info;
|
||||
} addr_info;
|
||||
};
|
||||
|
||||
Currently special info for only for SI_ACPI address sources is
|
||||
returned. Others may be added as necessary.
|
||||
|
||||
Note that the dev pointer is included in the above structure, and
|
||||
assuming ipmi_smi_get_info returns success, you must call put_device
|
||||
on the dev pointer.
|
||||
|
||||
|
||||
Watchdog
|
||||
--------
|
||||
|
||||
|
||||
@ -1,3 +1,3 @@
|
||||
obj-m := DocBook/ accounting/ auxdisplay/ connector/ \
|
||||
filesystems/ filesystems/configfs/ ia64/ laptops/ networking/ \
|
||||
pcmcia/ spi/ timers/ video4linux/ vm/ watchdog/src/
|
||||
pcmcia/ spi/ timers/ vm/ watchdog/src/
|
||||
|
||||
@ -1,18 +1,22 @@
|
||||
CONFIG_RCU_TRACE debugfs Files and Formats
|
||||
|
||||
|
||||
The rcutree implementation of RCU provides debugfs trace output that
|
||||
summarizes counters and state. This information is useful for debugging
|
||||
RCU itself, and can sometimes also help to debug abuses of RCU.
|
||||
The following sections describe the debugfs files and formats.
|
||||
The rcutree and rcutiny implementations of RCU provide debugfs trace
|
||||
output that summarizes counters and state. This information is useful for
|
||||
debugging RCU itself, and can sometimes also help to debug abuses of RCU.
|
||||
The following sections describe the debugfs files and formats, first
|
||||
for rcutree and next for rcutiny.
|
||||
|
||||
|
||||
Hierarchical RCU debugfs Files and Formats
|
||||
CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats
|
||||
|
||||
This implementation of RCU provides three debugfs files under the
|
||||
These implementations of RCU provides five debugfs files under the
|
||||
top-level directory RCU: rcu/rcudata (which displays fields in struct
|
||||
rcu_data), rcu/rcugp (which displays grace-period counters), and
|
||||
rcu/rcuhier (which displays the struct rcu_node hierarchy).
|
||||
rcu_data), rcu/rcudata.csv (which is a .csv spreadsheet version of
|
||||
rcu/rcudata), rcu/rcugp (which displays grace-period counters),
|
||||
rcu/rcuhier (which displays the struct rcu_node hierarchy), and
|
||||
rcu/rcu_pending (which displays counts of the reasons that the
|
||||
rcu_pending() function decided that there was core RCU work to do).
|
||||
|
||||
The output of "cat rcu/rcudata" looks as follows:
|
||||
|
||||
@ -130,7 +134,8 @@ o "ci" is the number of RCU callbacks that have been invoked for
|
||||
been registered in absence of CPU-hotplug activity.
|
||||
|
||||
o "co" is the number of RCU callbacks that have been orphaned due to
|
||||
this CPU going offline.
|
||||
this CPU going offline. These orphaned callbacks have been moved
|
||||
to an arbitrarily chosen online CPU.
|
||||
|
||||
o "ca" is the number of RCU callbacks that have been adopted due to
|
||||
other CPUs going offline. Note that ci+co-ca+ql is the number of
|
||||
@ -168,12 +173,12 @@ o "gpnum" is the number of grace periods that have started. It is
|
||||
|
||||
The output of "cat rcu/rcuhier" looks as follows, with very long lines:
|
||||
|
||||
c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6 oqlen=0
|
||||
c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6
|
||||
1/1 .>. 0:127 ^0
|
||||
3/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3
|
||||
3/3f .>. 0:5 ^0 2/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3
|
||||
rcu_bh:
|
||||
c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0 oqlen=0
|
||||
c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0
|
||||
0/1 .>. 0:127 ^0
|
||||
0/3 .>. 0:35 ^0 0/0 .>. 36:71 ^1 0/0 .>. 72:107 ^2 0/0 .>. 108:127 ^3
|
||||
0/3f .>. 0:5 ^0 0/3 .>. 6:11 ^1 0/0 .>. 12:17 ^2 0/0 .>. 18:23 ^3 0/0 .>. 24:29 ^4 0/0 .>. 30:35 ^5 0/0 .>. 36:41 ^0 0/0 .>. 42:47 ^1 0/0 .>. 48:53 ^2 0/0 .>. 54:59 ^3 0/0 .>. 60:65 ^4 0/0 .>. 66:71 ^5 0/0 .>. 72:77 ^0 0/0 .>. 78:83 ^1 0/0 .>. 84:89 ^2 0/0 .>. 90:95 ^3 0/0 .>. 96:101 ^4 0/0 .>. 102:107 ^5 0/0 .>. 108:113 ^0 0/0 .>. 114:119 ^1 0/0 .>. 120:125 ^2 0/0 .>. 126:127 ^3
|
||||
@ -212,11 +217,6 @@ o "fqlh" is the number of calls to force_quiescent_state() that
|
||||
exited immediately (without even being counted in nfqs above)
|
||||
due to contention on ->fqslock.
|
||||
|
||||
o "oqlen" is the number of callbacks on the "orphan" callback
|
||||
list. RCU callbacks are placed on this list by CPUs going
|
||||
offline, and are "adopted" either by the CPU helping the outgoing
|
||||
CPU or by the next rcu_barrier*() call, whichever comes first.
|
||||
|
||||
o Each element of the form "1/1 0:127 ^0" represents one struct
|
||||
rcu_node. Each line represents one level of the hierarchy, from
|
||||
root to leaves. It is best to think of the rcu_data structures
|
||||
@ -326,3 +326,115 @@ o "nn" is the number of times that this CPU needed nothing. Alert
|
||||
readers will note that the rcu "nn" number for a given CPU very
|
||||
closely matches the rcu_bh "np" number for that same CPU. This
|
||||
is due to short-circuit evaluation in rcu_pending().
|
||||
|
||||
|
||||
CONFIG_TINY_RCU and CONFIG_TINY_PREEMPT_RCU debugfs Files and Formats
|
||||
|
||||
These implementations of RCU provides a single debugfs file under the
|
||||
top-level directory RCU, namely rcu/rcudata, which displays fields in
|
||||
rcu_bh_ctrlblk, rcu_sched_ctrlblk and, for CONFIG_TINY_PREEMPT_RCU,
|
||||
rcu_preempt_ctrlblk.
|
||||
|
||||
The output of "cat rcu/rcudata" is as follows:
|
||||
|
||||
rcu_preempt: qlen=24 gp=1097669 g197/p197/c197 tasks=...
|
||||
ttb=. btg=no ntb=184 neb=0 nnb=183 j=01f7 bt=0274
|
||||
normal balk: nt=1097669 gt=0 bt=371 b=0 ny=25073378 nos=0
|
||||
exp balk: bt=0 nos=0
|
||||
rcu_sched: qlen: 0
|
||||
rcu_bh: qlen: 0
|
||||
|
||||
This is split into rcu_preempt, rcu_sched, and rcu_bh sections, with the
|
||||
rcu_preempt section appearing only in CONFIG_TINY_PREEMPT_RCU builds.
|
||||
The last three lines of the rcu_preempt section appear only in
|
||||
CONFIG_RCU_BOOST kernel builds. The fields are as follows:
|
||||
|
||||
o "qlen" is the number of RCU callbacks currently waiting either
|
||||
for an RCU grace period or waiting to be invoked. This is the
|
||||
only field present for rcu_sched and rcu_bh, due to the
|
||||
short-circuiting of grace period in those two cases.
|
||||
|
||||
o "gp" is the number of grace periods that have completed.
|
||||
|
||||
o "g197/p197/c197" displays the grace-period state, with the
|
||||
"g" number being the number of grace periods that have started
|
||||
(mod 256), the "p" number being the number of grace periods
|
||||
that the CPU has responded to (also mod 256), and the "c"
|
||||
number being the number of grace periods that have completed
|
||||
(once again mode 256).
|
||||
|
||||
Why have both "gp" and "g"? Because the data flowing into
|
||||
"gp" is only present in a CONFIG_RCU_TRACE kernel.
|
||||
|
||||
o "tasks" is a set of bits. The first bit is "T" if there are
|
||||
currently tasks that have recently blocked within an RCU
|
||||
read-side critical section, the second bit is "N" if any of the
|
||||
aforementioned tasks are blocking the current RCU grace period,
|
||||
and the third bit is "E" if any of the aforementioned tasks are
|
||||
blocking the current expedited grace period. Each bit is "."
|
||||
if the corresponding condition does not hold.
|
||||
|
||||
o "ttb" is a single bit. It is "B" if any of the blocked tasks
|
||||
need to be priority boosted and "." otherwise.
|
||||
|
||||
o "btg" indicates whether boosting has been carried out during
|
||||
the current grace period, with "exp" indicating that boosting
|
||||
is in progress for an expedited grace period, "no" indicating
|
||||
that boosting has not yet started for a normal grace period,
|
||||
"begun" indicating that boosting has bebug for a normal grace
|
||||
period, and "done" indicating that boosting has completed for
|
||||
a normal grace period.
|
||||
|
||||
o "ntb" is the total number of tasks subjected to RCU priority boosting
|
||||
periods since boot.
|
||||
|
||||
o "neb" is the number of expedited grace periods that have had
|
||||
to resort to RCU priority boosting since boot.
|
||||
|
||||
o "nnb" is the number of normal grace periods that have had
|
||||
to resort to RCU priority boosting since boot.
|
||||
|
||||
o "j" is the low-order 12 bits of the jiffies counter in hexadecimal.
|
||||
|
||||
o "bt" is the low-order 12 bits of the value that the jiffies counter
|
||||
will have at the next time that boosting is scheduled to begin.
|
||||
|
||||
o In the line beginning with "normal balk", the fields are as follows:
|
||||
|
||||
o "nt" is the number of times that the system balked from
|
||||
boosting because there were no blocked tasks to boost.
|
||||
Note that the system will balk from boosting even if the
|
||||
grace period is overdue when the currently running task
|
||||
is looping within an RCU read-side critical section.
|
||||
There is no point in boosting in this case, because
|
||||
boosting a running task won't make it run any faster.
|
||||
|
||||
o "gt" is the number of times that the system balked
|
||||
from boosting because, although there were blocked tasks,
|
||||
none of them were preventing the current grace period
|
||||
from completing.
|
||||
|
||||
o "bt" is the number of times that the system balked
|
||||
from boosting because boosting was already in progress.
|
||||
|
||||
o "b" is the number of times that the system balked from
|
||||
boosting because boosting had already completed for
|
||||
the grace period in question.
|
||||
|
||||
o "ny" is the number of times that the system balked from
|
||||
boosting because it was not yet time to start boosting
|
||||
the grace period in question.
|
||||
|
||||
o "nos" is the number of times that the system balked from
|
||||
boosting for inexplicable ("not otherwise specified")
|
||||
reasons. This can actually happen due to races involving
|
||||
increments of the jiffies counter.
|
||||
|
||||
o In the line beginning with "exp balk", the fields are as follows:
|
||||
|
||||
o "bt" is the number of times that the system balked from
|
||||
boosting because there were no blocked tasks to boost.
|
||||
|
||||
o "nos" is the number of times that the system balked from
|
||||
boosting for inexplicable ("not otherwise specified")
|
||||
reasons.
|
||||
|
||||
@ -516,6 +516,7 @@ int main(int argc, char *argv[])
|
||||
default:
|
||||
fprintf(stderr, "Unknown nla_type %d\n",
|
||||
na->nla_type);
|
||||
case TASKSTATS_TYPE_NULL:
|
||||
break;
|
||||
}
|
||||
na = (struct nlattr *) (GENLMSG_DATA(&msg) + len);
|
||||
|
||||
122
Documentation/acpi/apei/output_format.txt
Normal file
122
Documentation/acpi/apei/output_format.txt
Normal file
@ -0,0 +1,122 @@
|
||||
APEI output format
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
APEI uses printk as hardware error reporting interface, the output
|
||||
format is as follow.
|
||||
|
||||
<error record> :=
|
||||
APEI generic hardware error status
|
||||
severity: <integer>, <severity string>
|
||||
section: <integer>, severity: <integer>, <severity string>
|
||||
flags: <integer>
|
||||
<section flags strings>
|
||||
fru_id: <uuid string>
|
||||
fru_text: <string>
|
||||
section_type: <section type string>
|
||||
<section data>
|
||||
|
||||
<severity string>* := recoverable | fatal | corrected | info
|
||||
|
||||
<section flags strings># :=
|
||||
[primary][, containment warning][, reset][, threshold exceeded]\
|
||||
[, resource not accessible][, latent error]
|
||||
|
||||
<section type string> := generic processor error | memory error | \
|
||||
PCIe error | unknown, <uuid string>
|
||||
|
||||
<section data> :=
|
||||
<generic processor section data> | <memory section data> | \
|
||||
<pcie section data> | <null>
|
||||
|
||||
<generic processor section data> :=
|
||||
[processor_type: <integer>, <proc type string>]
|
||||
[processor_isa: <integer>, <proc isa string>]
|
||||
[error_type: <integer>
|
||||
<proc error type strings>]
|
||||
[operation: <integer>, <proc operation string>]
|
||||
[flags: <integer>
|
||||
<proc flags strings>]
|
||||
[level: <integer>]
|
||||
[version_info: <integer>]
|
||||
[processor_id: <integer>]
|
||||
[target_address: <integer>]
|
||||
[requestor_id: <integer>]
|
||||
[responder_id: <integer>]
|
||||
[IP: <integer>]
|
||||
|
||||
<proc type string>* := IA32/X64 | IA64
|
||||
|
||||
<proc isa string>* := IA32 | IA64 | X64
|
||||
|
||||
<processor error type strings># :=
|
||||
[cache error][, TLB error][, bus error][, micro-architectural error]
|
||||
|
||||
<proc operation string>* := unknown or generic | data read | data write | \
|
||||
instruction execution
|
||||
|
||||
<proc flags strings># :=
|
||||
[restartable][, precise IP][, overflow][, corrected]
|
||||
|
||||
<memory section data> :=
|
||||
[error_status: <integer>]
|
||||
[physical_address: <integer>]
|
||||
[physical_address_mask: <integer>]
|
||||
[node: <integer>]
|
||||
[card: <integer>]
|
||||
[module: <integer>]
|
||||
[bank: <integer>]
|
||||
[device: <integer>]
|
||||
[row: <integer>]
|
||||
[column: <integer>]
|
||||
[bit_position: <integer>]
|
||||
[requestor_id: <integer>]
|
||||
[responder_id: <integer>]
|
||||
[target_id: <integer>]
|
||||
[error_type: <integer>, <mem error type string>]
|
||||
|
||||
<mem error type string>* :=
|
||||
unknown | no error | single-bit ECC | multi-bit ECC | \
|
||||
single-symbol chipkill ECC | multi-symbol chipkill ECC | master abort | \
|
||||
target abort | parity error | watchdog timeout | invalid address | \
|
||||
mirror Broken | memory sparing | scrub corrected error | \
|
||||
scrub uncorrected error
|
||||
|
||||
<pcie section data> :=
|
||||
[port_type: <integer>, <pcie port type string>]
|
||||
[version: <integer>.<integer>]
|
||||
[command: <integer>, status: <integer>]
|
||||
[device_id: <integer>:<integer>:<integer>.<integer>
|
||||
slot: <integer>
|
||||
secondary_bus: <integer>
|
||||
vendor_id: <integer>, device_id: <integer>
|
||||
class_code: <integer>]
|
||||
[serial number: <integer>, <integer>]
|
||||
[bridge: secondary_status: <integer>, control: <integer>]
|
||||
|
||||
<pcie port type string>* := PCIe end point | legacy PCI end point | \
|
||||
unknown | unknown | root port | upstream switch port | \
|
||||
downstream switch port | PCIe to PCI/PCI-X bridge | \
|
||||
PCI/PCI-X to PCIe bridge | root complex integrated endpoint device | \
|
||||
root complex event collector
|
||||
|
||||
Where, [] designate corresponding content is optional
|
||||
|
||||
All <field string> description with * has the following format:
|
||||
|
||||
field: <integer>, <field string>
|
||||
|
||||
Where value of <integer> should be the position of "string" in <field
|
||||
string> description. Otherwise, <field string> will be "unknown".
|
||||
|
||||
All <field strings> description with # has the following format:
|
||||
|
||||
field: <integer>
|
||||
<field strings>
|
||||
|
||||
Where each string in <fields strings> corresponding to one set bit of
|
||||
<integer>. The bit position is the position of "string" in <field
|
||||
strings> description.
|
||||
|
||||
For more detailed explanation of every field, please refer to UEFI
|
||||
specification version 2.3 or later, section Appendix N: Common
|
||||
Platform Error Record.
|
||||
@ -34,3 +34,5 @@ memory.txt
|
||||
- description of the virtual memory layout
|
||||
nwfpe/
|
||||
- NWFPE floating point emulator documentation
|
||||
swp_emulation
|
||||
- SWP/SWPB emulation handler/logging description
|
||||
|
||||
@ -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,
|
||||
|
||||
@ -127,3 +127,28 @@ implementation needs:
|
||||
10. (*pdata->cpu_set_freq)(unsigned long f)
|
||||
|
||||
11. (*pdata->cpu_get_freq)(void)
|
||||
|
||||
Customizing OPP for platform
|
||||
============================
|
||||
Defining CONFIG_PM should enable OPP layer for the silicon
|
||||
and the registration of OPP table should take place automatically.
|
||||
However, in special cases, the default OPP table may need to be
|
||||
tweaked, for e.g.:
|
||||
* enable default OPPs which are disabled by default, but which
|
||||
could be enabled on a platform
|
||||
* Disable an unsupported OPP on the platform
|
||||
* Define and add a custom opp table entry
|
||||
in these cases, the board file needs to do additional steps as follows:
|
||||
arch/arm/mach-omapx/board-xyz.c
|
||||
#include "pm.h"
|
||||
....
|
||||
static void __init omap_xyz_init_irq(void)
|
||||
{
|
||||
....
|
||||
/* Initialize the default table */
|
||||
omapx_opp_init();
|
||||
/* Do customization to the defaults */
|
||||
....
|
||||
}
|
||||
NOTE: omapx_opp_init will be omap3_opp_init or as required
|
||||
based on the omap family.
|
||||
|
||||
27
Documentation/arm/swp_emulation
Normal file
27
Documentation/arm/swp_emulation
Normal file
@ -0,0 +1,27 @@
|
||||
Software emulation of deprecated SWP instruction (CONFIG_SWP_EMULATE)
|
||||
---------------------------------------------------------------------
|
||||
|
||||
ARMv6 architecture deprecates use of the SWP/SWPB instructions, and recommeds
|
||||
moving to the load-locked/store-conditional instructions LDREX and STREX.
|
||||
|
||||
ARMv7 multiprocessing extensions introduce the ability to disable these
|
||||
instructions, triggering an undefined instruction exception when executed.
|
||||
Trapped instructions are emulated using an LDREX/STREX or LDREXB/STREXB
|
||||
sequence. If a memory access fault (an abort) occurs, a segmentation fault is
|
||||
signalled to the triggering process.
|
||||
|
||||
/proc/cpu/swp_emulation holds some statistics/information, including the PID of
|
||||
the last process to trigger the emulation to be invocated. For example:
|
||||
---
|
||||
Emulated SWP: 12
|
||||
Emulated SWPB: 0
|
||||
Aborted SWP{B}: 1
|
||||
Last process: 314
|
||||
---
|
||||
|
||||
NOTE: when accessing uncached shared regions, LDREX/STREX rely on an external
|
||||
transaction monitoring block called a global monitor to maintain update
|
||||
atomicity. If your system does not implement a global monitor, this option can
|
||||
cause programs that perform SWP operations to uncached memory to deadlock, as
|
||||
the STREX operation will always fail.
|
||||
|
||||
@ -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:
|
||||
@ -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
|
||||
|
||||
@ -89,6 +89,33 @@ Throttling/Upper Limit policy
|
||||
|
||||
Limits for writes can be put using blkio.write_bps_device file.
|
||||
|
||||
Hierarchical Cgroups
|
||||
====================
|
||||
- Currently none of the IO control policy supports hierarhical groups. But
|
||||
cgroup interface does allow creation of hierarhical cgroups and internally
|
||||
IO policies treat them as flat hierarchy.
|
||||
|
||||
So this patch will allow creation of cgroup hierarhcy but at the backend
|
||||
everything will be treated as flat. So if somebody created a hierarchy like
|
||||
as follows.
|
||||
|
||||
root
|
||||
/ \
|
||||
test1 test2
|
||||
|
|
||||
test3
|
||||
|
||||
CFQ and throttling will practically treat all groups at same level.
|
||||
|
||||
pivot
|
||||
/ | \ \
|
||||
root test1 test2 test3
|
||||
|
||||
Down the line we can implement hierarchical accounting/control support
|
||||
and also introduce a new cgroup file "use_hierarchy" which will control
|
||||
whether cgroup hierarchy is viewed as flat or hierarchical by the policy..
|
||||
This is how memory controller also has implemented the things.
|
||||
|
||||
Various user visible config options
|
||||
===================================
|
||||
CONFIG_BLK_CGROUP
|
||||
|
||||
@ -91,7 +91,7 @@ int main(int argc, char **argv)
|
||||
|
||||
if (ret == -1) {
|
||||
perror("cgroup.event_control "
|
||||
"is not accessable any more");
|
||||
"is not accessible any more");
|
||||
break;
|
||||
}
|
||||
|
||||
|
||||
@ -355,13 +355,13 @@ subsystems, type:
|
||||
|
||||
To change the set of subsystems bound to a mounted hierarchy, just
|
||||
remount with different options:
|
||||
# mount -o remount,cpuset,ns hier1 /dev/cgroup
|
||||
# mount -o remount,cpuset,blkio hier1 /dev/cgroup
|
||||
|
||||
Now memory is removed from the hierarchy and ns is added.
|
||||
Now memory is removed from the hierarchy and blkio is added.
|
||||
|
||||
Note this will add ns to the hierarchy but won't remove memory or
|
||||
Note this will add blkio to the hierarchy but won't remove memory or
|
||||
cpuset, because the new options are appended to the old ones:
|
||||
# mount -o remount,ns /dev/cgroup
|
||||
# mount -o remount,blkio /dev/cgroup
|
||||
|
||||
To Specify a hierarchy's release_agent:
|
||||
# mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \
|
||||
|
||||
@ -398,7 +398,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
||||
written to move_charge_at_immigrate.
|
||||
|
||||
9.10 Memory thresholds
|
||||
Memory controler implements memory thresholds using cgroups notification
|
||||
Memory controller implements memory thresholds using cgroups notification
|
||||
API. You can use Documentation/cgroups/cgroup_event_listener.c to test
|
||||
it.
|
||||
|
||||
|
||||
@ -36,6 +36,10 @@ as a regular user, and install it with
|
||||
|
||||
sudo make install
|
||||
|
||||
The semantic patches in the kernel will work best with Coccinelle version
|
||||
0.2.4 or later. Using earlier versions may incur some parse errors in the
|
||||
semantic patch code, but any results that are obtained should still be
|
||||
correct.
|
||||
|
||||
Using Coccinelle on the Linux kernel
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -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.
|
||||
@ -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
|
||||
@ -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
|
||||
@ -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
|
||||
@ -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
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ Parameters: <cipher> <key> <iv_offset> <device path> <offset>
|
||||
|
||||
<cipher>
|
||||
Encryption cipher and an optional IV generation mode.
|
||||
(In format cipher-chainmode-ivopts:ivmode).
|
||||
(In format cipher[:keycount]-chainmode-ivopts:ivmode).
|
||||
Examples:
|
||||
des
|
||||
aes-cbc-essiv:sha256
|
||||
@ -20,6 +20,11 @@ Parameters: <cipher> <key> <iv_offset> <device path> <offset>
|
||||
Key used for encryption. It is encoded as a hexadecimal number.
|
||||
You can only use key sizes that are valid for the selected cipher.
|
||||
|
||||
<keycount>
|
||||
Multi-key compatibility mode. You can define <keycount> keys and
|
||||
then sectors are encrypted according to their offsets (sector 0 uses key0;
|
||||
sector 1 uses key1 etc.). <keycount> must be a power of two.
|
||||
|
||||
<iv_offset>
|
||||
The IV offset is a sector count that is added to the sector number
|
||||
before creating the IV.
|
||||
|
||||
70
Documentation/device-mapper/dm-raid.txt
Normal file
70
Documentation/device-mapper/dm-raid.txt
Normal file
@ -0,0 +1,70 @@
|
||||
Device-mapper RAID (dm-raid) is a bridge from DM to MD. It
|
||||
provides a way to use device-mapper interfaces to access the MD RAID
|
||||
drivers.
|
||||
|
||||
As with all device-mapper targets, the nominal public interfaces are the
|
||||
constructor (CTR) tables and the status outputs (both STATUSTYPE_INFO
|
||||
and STATUSTYPE_TABLE). The CTR table looks like the following:
|
||||
|
||||
1: <s> <l> raid \
|
||||
2: <raid_type> <#raid_params> <raid_params> \
|
||||
3: <#raid_devs> <meta_dev1> <dev1> .. <meta_devN> <devN>
|
||||
|
||||
Line 1 contains the standard first three arguments to any device-mapper
|
||||
target - the start, length, and target type fields. The target type in
|
||||
this case is "raid".
|
||||
|
||||
Line 2 contains the arguments that define the particular raid
|
||||
type/personality/level, the required arguments for that raid type, and
|
||||
any optional arguments. Possible raid types include: raid4, raid5_la,
|
||||
raid5_ls, raid5_rs, raid6_zr, raid6_nr, and raid6_nc. (raid1 is
|
||||
planned for the future.) The list of required and optional parameters
|
||||
is the same for all the current raid types. The required parameters are
|
||||
positional, while the optional parameters are given as key/value pairs.
|
||||
The possible parameters are as follows:
|
||||
<chunk_size> Chunk size in sectors.
|
||||
[[no]sync] Force/Prevent RAID initialization
|
||||
[rebuild <idx>] Rebuild the drive indicated by the index
|
||||
[daemon_sleep <ms>] Time between bitmap daemon work to clear bits
|
||||
[min_recovery_rate <kB/sec/disk>] Throttle RAID initialization
|
||||
[max_recovery_rate <kB/sec/disk>] Throttle RAID initialization
|
||||
[max_write_behind <sectors>] See '-write-behind=' (man mdadm)
|
||||
[stripe_cache <sectors>] Stripe cache size for higher RAIDs
|
||||
|
||||
Line 3 contains the list of devices that compose the array in
|
||||
metadata/data device pairs. If the metadata is stored separately, a '-'
|
||||
is given for the metadata device position. If a drive has failed or is
|
||||
missing at creation time, a '-' can be given for both the metadata and
|
||||
data drives for a given position.
|
||||
|
||||
NB. Currently all metadata devices must be specified as '-'.
|
||||
|
||||
Examples:
|
||||
# RAID4 - 4 data drives, 1 parity
|
||||
# No metadata devices specified to hold superblock/bitmap info
|
||||
# Chunk size of 1MiB
|
||||
# (Lines separated for easy reading)
|
||||
0 1960893648 raid \
|
||||
raid4 1 2048 \
|
||||
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
|
||||
|
||||
# RAID4 - 4 data drives, 1 parity (no metadata devices)
|
||||
# Chunk size of 1MiB, force RAID initialization,
|
||||
# min recovery rate at 20 kiB/sec/disk
|
||||
0 1960893648 raid \
|
||||
raid4 4 2048 min_recovery_rate 20 sync\
|
||||
5 - 8:17 - 8:33 - 8:49 - 8:65 - 8:81
|
||||
|
||||
Performing a 'dmsetup table' should display the CTR table used to
|
||||
construct the mapping (with possible reordering of optional
|
||||
parameters).
|
||||
|
||||
Performing a 'dmsetup status' will yield information on the state and
|
||||
health of the array. The output is as follows:
|
||||
1: <s> <l> raid \
|
||||
2: <raid_type> <#devices> <1 health char for each dev> <resync_ratio>
|
||||
|
||||
Line 1 is standard DM output. Line 2 is best shown by example:
|
||||
0 1960893648 raid raid4 5 AAAAA 2/490221568
|
||||
Here we can see the RAID type is raid4, there are 5 devices - all of
|
||||
which are 'A'live, and the array is 2/490221568 complete with recovery.
|
||||
@ -62,6 +62,10 @@ aic7*reg_print.c*
|
||||
aic7*seq.h*
|
||||
aicasm
|
||||
aicdb.h*
|
||||
altivec1.c
|
||||
altivec2.c
|
||||
altivec4.c
|
||||
altivec8.c
|
||||
asm-offsets.h
|
||||
asm_offsets.h
|
||||
autoconf.h*
|
||||
@ -76,6 +80,7 @@ btfixupprep
|
||||
build
|
||||
bvmlinux
|
||||
bzImage*
|
||||
capflags.c
|
||||
classlist.h*
|
||||
comp*.log
|
||||
compile.h*
|
||||
@ -94,6 +99,7 @@ devlist.h*
|
||||
docproc
|
||||
elf2ecoff
|
||||
elfconfig.h*
|
||||
evergreen_reg_safe.h
|
||||
fixdep
|
||||
flask.h
|
||||
fore200e_mkfirm
|
||||
@ -108,9 +114,16 @@ genksyms
|
||||
*_gray256.c
|
||||
ihex2fw
|
||||
ikconfig.h*
|
||||
inat-tables.c
|
||||
initramfs_data.cpio
|
||||
initramfs_data.cpio.gz
|
||||
initramfs_list
|
||||
int16.c
|
||||
int1.c
|
||||
int2.c
|
||||
int32.c
|
||||
int4.c
|
||||
int8.c
|
||||
kallsyms
|
||||
kconfig
|
||||
keywords.c
|
||||
@ -140,6 +153,7 @@ mkprep
|
||||
mktables
|
||||
mktree
|
||||
modpost
|
||||
modules.builtin
|
||||
modules.order
|
||||
modversions.h*
|
||||
ncscope.*
|
||||
@ -153,14 +167,23 @@ pca200e.bin
|
||||
pca200e_ecd.bin2
|
||||
piggy.gz
|
||||
piggyback
|
||||
piggy.S
|
||||
pnmtologo
|
||||
ppc_defs.h*
|
||||
pss_boot.h
|
||||
qconf
|
||||
r100_reg_safe.h
|
||||
r200_reg_safe.h
|
||||
r300_reg_safe.h
|
||||
r420_reg_safe.h
|
||||
r600_reg_safe.h
|
||||
raid6altivec*.c
|
||||
raid6int*.c
|
||||
raid6tables.c
|
||||
relocs
|
||||
rn50_reg_safe.h
|
||||
rs600_reg_safe.h
|
||||
rv515_reg_safe.h
|
||||
series
|
||||
setup
|
||||
setup.bin
|
||||
@ -169,6 +192,7 @@ sImage
|
||||
sm_tbl*
|
||||
split-include
|
||||
syscalltab.h
|
||||
tables.c
|
||||
tags
|
||||
tftpboot.img
|
||||
timeconst.h
|
||||
@ -190,6 +214,7 @@ vmlinux
|
||||
vmlinux-*
|
||||
vmlinux.aout
|
||||
vmlinux.lds
|
||||
voffset.h
|
||||
vsyscall.lds
|
||||
vsyscall_32.lds
|
||||
wanxlfw.inc
|
||||
@ -200,3 +225,4 @@ wakeup.elf
|
||||
wakeup.lds
|
||||
zImage*
|
||||
zconf.hash.c
|
||||
zoffset.h
|
||||
|
||||
@ -1,129 +0,0 @@
|
||||
|
||||
Device Interfaces
|
||||
|
||||
Introduction
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Device interfaces are the logical interfaces of device classes that correlate
|
||||
directly to userspace interfaces, like device nodes.
|
||||
|
||||
Each device class may have multiple interfaces through which you can
|
||||
access the same device. An input device may support the mouse interface,
|
||||
the 'evdev' interface, and the touchscreen interface. A SCSI disk would
|
||||
support the disk interface, the SCSI generic interface, and possibly a raw
|
||||
device interface.
|
||||
|
||||
Device interfaces are registered with the class they belong to. As devices
|
||||
are added to the class, they are added to each interface registered with
|
||||
the class. The interface is responsible for determining whether the device
|
||||
supports the interface or not.
|
||||
|
||||
|
||||
Programming Interface
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
struct device_interface {
|
||||
char * name;
|
||||
rwlock_t lock;
|
||||
u32 devnum;
|
||||
struct device_class * devclass;
|
||||
|
||||
struct list_head node;
|
||||
struct driver_dir_entry dir;
|
||||
|
||||
int (*add_device)(struct device *);
|
||||
int (*add_device)(struct intf_data *);
|
||||
};
|
||||
|
||||
int interface_register(struct device_interface *);
|
||||
void interface_unregister(struct device_interface *);
|
||||
|
||||
|
||||
An interface must specify the device class it belongs to. It is added
|
||||
to that class's list of interfaces on registration.
|
||||
|
||||
|
||||
Interfaces can be added to a device class at any time. Whenever it is
|
||||
added, each device in the class is passed to the interface's
|
||||
add_device callback. When an interface is removed, each device is
|
||||
removed from the interface.
|
||||
|
||||
|
||||
Devices
|
||||
~~~~~~~
|
||||
Once a device is added to a device class, it is added to each
|
||||
interface that is registered with the device class. The class
|
||||
is expected to place a class-specific data structure in
|
||||
struct device::class_data. The interface can use that (along with
|
||||
other fields of struct device) to determine whether or not the driver
|
||||
and/or device support that particular interface.
|
||||
|
||||
|
||||
Data
|
||||
~~~~
|
||||
|
||||
struct intf_data {
|
||||
struct list_head node;
|
||||
struct device_interface * intf;
|
||||
struct device * dev;
|
||||
u32 intf_num;
|
||||
};
|
||||
|
||||
int interface_add_data(struct interface_data *);
|
||||
|
||||
The interface is responsible for allocating and initializing a struct
|
||||
intf_data and calling interface_add_data() to add it to the device's list
|
||||
of interfaces it belongs to. This list will be iterated over when the device
|
||||
is removed from the class (instead of all possible interfaces for a class).
|
||||
This structure should probably be embedded in whatever per-device data
|
||||
structure the interface is allocating anyway.
|
||||
|
||||
Devices are enumerated within the interface. This happens in interface_add_data()
|
||||
and the enumerated value is stored in the struct intf_data for that device.
|
||||
|
||||
sysfs
|
||||
~~~~~
|
||||
Each interface is given a directory in the directory of the device
|
||||
class it belongs to:
|
||||
|
||||
Interfaces get a directory in the class's directory as well:
|
||||
|
||||
class/
|
||||
`-- input
|
||||
|-- devices
|
||||
|-- drivers
|
||||
|-- mouse
|
||||
`-- evdev
|
||||
|
||||
When a device is added to the interface, a symlink is created that points
|
||||
to the device's directory in the physical hierarchy:
|
||||
|
||||
class/
|
||||
`-- input
|
||||
|-- devices
|
||||
| `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
|
||||
|-- drivers
|
||||
| `-- usb:usb_mouse -> ../../../bus/drivers/usb_mouse/
|
||||
|-- mouse
|
||||
| `-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
|
||||
`-- evdev
|
||||
`-- 1 -> ../../../root/pci0/00:1f.0/usb_bus/00:1f.2-1:0/
|
||||
|
||||
|
||||
Future Plans
|
||||
~~~~~~~~~~~~
|
||||
A device interface is correlated directly with a userspace interface
|
||||
for a device, specifically a device node. For instance, a SCSI disk
|
||||
exposes at least two interfaces to userspace: the standard SCSI disk
|
||||
interface and the SCSI generic interface. It might also export a raw
|
||||
device interface.
|
||||
|
||||
Many interfaces have a major number associated with them and each
|
||||
device gets a minor number. Or, multiple interfaces might share one
|
||||
major number, and each will receive a range of minor numbers (like in
|
||||
the case of input devices).
|
||||
|
||||
These major and minor numbers could be stored in the interface
|
||||
structure. Major and minor allocations could happen when the interface
|
||||
is registered with the class, or via a helper function.
|
||||
|
||||
@ -46,7 +46,7 @@ and run
|
||||
Other LG firmware can be extracted manually from US280D.sys
|
||||
only found in windows/system32/driver.
|
||||
|
||||
dd if=US280D.sys ibs=1 skip=42616 count=3668 of=dvb-usb-lme2510-lg.fw
|
||||
dd if=US280D.sys ibs=1 skip=42360 count=3924 of=dvb-usb-lme2510-lg.fw
|
||||
|
||||
for DM04 LME2510C (LG Tuner)
|
||||
---------------------------
|
||||
|
||||
@ -196,7 +196,7 @@ csrow3.
|
||||
The representation of the above is reflected in the directory tree
|
||||
in EDAC's sysfs interface. Starting in directory
|
||||
/sys/devices/system/edac/mc each memory controller will be represented
|
||||
by its own 'mcX' directory, where 'X" is the index of the MC.
|
||||
by its own 'mcX' directory, where 'X' is the index of the MC.
|
||||
|
||||
|
||||
..../edac/mc/
|
||||
@ -207,7 +207,7 @@ by its own 'mcX' directory, where 'X" is the index of the MC.
|
||||
....
|
||||
|
||||
Under each 'mcX' directory each 'csrowX' is again represented by a
|
||||
'csrowX', where 'X" is the csrow index:
|
||||
'csrowX', where 'X' is the csrow index:
|
||||
|
||||
|
||||
.../mc/mc0/
|
||||
@ -232,7 +232,7 @@ EDAC control and attribute files.
|
||||
|
||||
|
||||
In 'mcX' directories are EDAC control and attribute files for
|
||||
this 'X" instance of the memory controllers:
|
||||
this 'X' instance of the memory controllers:
|
||||
|
||||
|
||||
Counter reset control file:
|
||||
@ -343,7 +343,7 @@ Sdram memory scrubbing rate:
|
||||
'csrowX' DIRECTORIES
|
||||
|
||||
In the 'csrowX' directories are EDAC control and attribute files for
|
||||
this 'X" instance of csrow:
|
||||
this 'X' instance of csrow:
|
||||
|
||||
|
||||
Total Uncorrectable Errors count attribute file:
|
||||
|
||||
@ -104,6 +104,13 @@ Then from the "Message" menu item, select insert file and choose your patch.
|
||||
As an added bonus you can customise the message creation toolbar menu
|
||||
and put the "insert file" icon there.
|
||||
|
||||
Make the the composer window wide enough so that no lines wrap. As of
|
||||
KMail 1.13.5 (KDE 4.5.4), KMail will apply word wrapping when sending
|
||||
the email if the lines wrap in the composer window. Having word wrapping
|
||||
disabled in the Options menu isn't enough. Thus, if your patch has very
|
||||
long lines, you must make the composer window very wide before sending
|
||||
the email. See: https://bugs.kde.org/show_bug.cgi?id=174034
|
||||
|
||||
You can safely GPG sign attachments, but inlined text is preferred for
|
||||
patches so do not GPG sign them. Signing patches that have been inserted
|
||||
as inlined text will make them tricky to extract from their 7-bit encoding.
|
||||
@ -179,26 +186,8 @@ Sylpheed (GUI)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Thunderbird (GUI)
|
||||
|
||||
By default, thunderbird likes to mangle text, but there are ways to
|
||||
coerce it into being nice.
|
||||
|
||||
- Under account settings, composition and addressing, uncheck "Compose
|
||||
messages in HTML format".
|
||||
|
||||
- Edit your Thunderbird config settings to tell it not to wrap lines:
|
||||
user_pref("mailnews.wraplength", 0);
|
||||
|
||||
- Edit your Thunderbird config settings so that it won't use format=flowed:
|
||||
user_pref("mailnews.send_plaintext_flowed", false);
|
||||
|
||||
- You need to get Thunderbird into preformat mode:
|
||||
. If you compose HTML messages by default, it's not too hard. Just select
|
||||
"Preformat" from the drop-down box just under the subject line.
|
||||
. If you compose in text by default, you have to tell it to compose a new
|
||||
message in HTML (just as a one-off), and then force it from there back to
|
||||
text, else it will wrap lines. To do this, use shift-click on the Write
|
||||
icon to compose to get HTML compose mode, then select "Preformat" from
|
||||
the drop-down box just under the subject line.
|
||||
Thunderbird is an Outlook clone that likes to mangle text, but there are ways
|
||||
to coerce it into behaving.
|
||||
|
||||
- Allows use of an external editor:
|
||||
The easiest thing to do with Thunderbird and patches is to use an
|
||||
@ -208,6 +197,27 @@ coerce it into being nice.
|
||||
View->Toolbars->Customize... and finally just click on it when in the
|
||||
Compose dialog.
|
||||
|
||||
To beat some sense out of the internal editor, do this:
|
||||
|
||||
- Under account settings, composition and addressing, uncheck "Compose
|
||||
messages in HTML format".
|
||||
|
||||
- Edit your Thunderbird config settings so that it won't use format=flowed.
|
||||
Go to "edit->preferences->advanced->config editor" to bring up the
|
||||
thunderbird's registry editor, and set "mailnews.send_plaintext_flowed" to
|
||||
"false".
|
||||
|
||||
- Enable "preformat" mode: Shft-click on the Write icon to bring up the HTML
|
||||
composer, select "Preformat" from the drop-down box just under the subject
|
||||
line, then close the message without saving. (This setting also applies to
|
||||
the text composer, but the only control for it is in the HTML composer.)
|
||||
|
||||
- Install the "toggle wordwrap" extension. Download the file from:
|
||||
https://addons.mozilla.org/thunderbird/addon/2351/
|
||||
Then go to "tools->add ons", select "install" at the bottom of the screen,
|
||||
and browse to where you saved the .xul file. This adds an "Enable
|
||||
Wordwrap" entry under the Options menu of the message composer.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
TkRat (GUI)
|
||||
|
||||
|
||||
@ -4,33 +4,41 @@ please mail me.
|
||||
Geert Uytterhoeven <geert@linux-m68k.org>
|
||||
|
||||
00-INDEX
|
||||
- this file
|
||||
- this file.
|
||||
arkfb.txt
|
||||
- info on the fbdev driver for ARK Logic chips.
|
||||
aty128fb.txt
|
||||
- info on the ATI Rage128 frame buffer driver.
|
||||
cirrusfb.txt
|
||||
- info on the driver for Cirrus Logic chipsets.
|
||||
cmap_xfbdev.txt
|
||||
- an introduction to fbdev's cmap structures.
|
||||
deferred_io.txt
|
||||
- an introduction to deferred IO.
|
||||
efifb.txt
|
||||
- info on the EFI platform driver for Intel based Apple computers.
|
||||
ep93xx-fb.txt
|
||||
- info on the driver for EP93xx LCD controller.
|
||||
fbcon.txt
|
||||
- intro to and usage guide for the framebuffer console (fbcon).
|
||||
framebuffer.txt
|
||||
- introduction to frame buffer devices.
|
||||
imacfb.txt
|
||||
- info on the generic EFI platform driver for Intel based Macs.
|
||||
gxfb.txt
|
||||
- info on the framebuffer driver for AMD Geode GX2 based processors.
|
||||
intel810.txt
|
||||
- documentation for the Intel 810/815 framebuffer driver.
|
||||
intelfb.txt
|
||||
- docs for Intel 830M/845G/852GM/855GM/865G/915G/945G fb driver.
|
||||
internals.txt
|
||||
- quick overview of frame buffer device internals.
|
||||
lxfb.txt
|
||||
- info on the framebuffer driver for AMD Geode LX based processors.
|
||||
matroxfb.txt
|
||||
- info on the Matrox framebuffer driver for Alpha, Intel and PPC.
|
||||
metronomefb.txt
|
||||
- info on the driver for the Metronome display controller.
|
||||
modedb.txt
|
||||
- info on the video mode database.
|
||||
matroxfb.txt
|
||||
- info on the Matrox frame buffer driver.
|
||||
pvr2fb.txt
|
||||
- info on the PowerVR 2 frame buffer driver.
|
||||
pxafb.txt
|
||||
@ -39,13 +47,23 @@ s3fb.txt
|
||||
- info on the fbdev driver for S3 Trio/Virge chips.
|
||||
sa1100fb.txt
|
||||
- information about the driver for the SA-1100 LCD controller.
|
||||
sh7760fb.txt
|
||||
- info on the SH7760/SH7763 integrated LCDC Framebuffer driver.
|
||||
sisfb.txt
|
||||
- info on the framebuffer device driver for various SiS chips.
|
||||
sstfb.txt
|
||||
- info on the frame buffer driver for 3dfx' Voodoo Graphics boards.
|
||||
tgafb.txt
|
||||
- info on the TGA (DECChip 21030) frame buffer driver
|
||||
- info on the TGA (DECChip 21030) frame buffer driver.
|
||||
tridentfb.txt
|
||||
info on the framebuffer driver for some Trident chip based cards.
|
||||
uvesafb.txt
|
||||
- info on the userspace VESA (VBE2+ compliant) frame buffer device.
|
||||
vesafb.txt
|
||||
- info on the VESA frame buffer device
|
||||
- info on the VESA frame buffer device.
|
||||
viafb.modes
|
||||
- list of modes for VIA Integration Graphic Chip.
|
||||
viafb.txt
|
||||
- info on the VIA Integration Graphic Chip console framebuffer driver.
|
||||
vt8623fb.txt
|
||||
- info on the fb driver for the graphics core in VIA VT8623 chipsets.
|
||||
|
||||
@ -97,36 +97,38 @@ Who: Pavel Machek <pavel@ucw.cz>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Video4Linux API 1 ioctls and from Video devices.
|
||||
When: kernel 2.6.38
|
||||
Files: include/linux/videodev.h
|
||||
Check: include/linux/videodev.h
|
||||
Why: V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6
|
||||
series. The old API have lots of drawbacks and don't provide enough
|
||||
means to work with all video and audio standards. The newer API is
|
||||
already available on the main drivers and should be used instead.
|
||||
Newer drivers should use v4l_compat_translate_ioctl function to handle
|
||||
old calls, replacing to newer ones.
|
||||
Decoder iocts are using internally to allow video drivers to
|
||||
communicate with video decoders. This should also be improved to allow
|
||||
V4L2 calls being translated into compatible internal ioctls.
|
||||
Compatibility ioctls will be provided, for a while, via
|
||||
v4l1-compat module.
|
||||
Who: Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Video4Linux obsolete drivers using V4L1 API
|
||||
When: kernel 2.6.38
|
||||
Files: drivers/staging/cpia/* drivers/staging/stradis/*
|
||||
Check: drivers/staging/cpia/cpia.c drivers/staging/stradis/stradis.c
|
||||
When: kernel 2.6.39
|
||||
Files: drivers/staging/se401/* drivers/staging/usbvideo/*
|
||||
Check: drivers/staging/se401/se401.c drivers/staging/usbvideo/usbvideo.c
|
||||
Why: There are some drivers still using V4L1 API, despite all efforts we've done
|
||||
to migrate. Those drivers are for obsolete hardware that the old maintainer
|
||||
didn't care (or not have the hardware anymore), and that no other developer
|
||||
could find any hardware to buy. They probably have no practical usage today,
|
||||
and people with such old hardware could probably keep using an older version
|
||||
of the kernel. Those drivers will be moved to staging on 2.6.37 and, if nobody
|
||||
care enough to port and test them with V4L2 API, they'll be removed on 2.6.38.
|
||||
of the kernel. Those drivers will be moved to staging on 2.6.38 and, if nobody
|
||||
cares enough to port and test them with V4L2 API, they'll be removed on 2.6.39.
|
||||
Who: Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: Video4Linux: Remove obsolete ioctl's
|
||||
When: kernel 2.6.39
|
||||
Files: include/media/videodev2.h
|
||||
Why: Some ioctl's were defined wrong on 2.6.2 and 2.6.6, using the wrong
|
||||
type of R/W arguments. They were fixed, but the old ioctl names are
|
||||
still there, maintained to avoid breaking binary compatibility:
|
||||
#define VIDIOC_OVERLAY_OLD _IOWR('V', 14, int)
|
||||
#define VIDIOC_S_PARM_OLD _IOW('V', 22, struct v4l2_streamparm)
|
||||
#define VIDIOC_S_CTRL_OLD _IOW('V', 28, struct v4l2_control)
|
||||
#define VIDIOC_G_AUDIO_OLD _IOWR('V', 33, struct v4l2_audio)
|
||||
#define VIDIOC_G_AUDOUT_OLD _IOWR('V', 49, struct v4l2_audioout)
|
||||
#define VIDIOC_CROPCAP_OLD _IOR('V', 58, struct v4l2_cropcap)
|
||||
There's no sense on preserving those forever, as it is very doubtful
|
||||
that someone would try to use a such old binary with a modern kernel.
|
||||
Removing them will allow us to remove some magic done at the V4L ioctl
|
||||
handler.
|
||||
|
||||
Who: Mauro Carvalho Chehab <mchehab@infradead.org>
|
||||
|
||||
---------------------------
|
||||
@ -191,6 +193,20 @@ Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's
|
||||
|
||||
---------------------------
|
||||
|
||||
What: CS5535/CS5536 obsolete GPIO driver
|
||||
When: June 2011
|
||||
Files: drivers/staging/cs5535_gpio/*
|
||||
Check: drivers/staging/cs5535_gpio/cs5535_gpio.c
|
||||
Why: A newer driver replaces this; it is drivers/gpio/cs5535-gpio.c, and
|
||||
integrates with the Linux GPIO subsystem. The old driver has been
|
||||
moved to staging, and will be removed altogether around 2.6.40.
|
||||
Please test the new driver, and ensure that the functionality you
|
||||
need and any bugfixes from the old driver are available in the new
|
||||
one.
|
||||
Who: Andres Salomon <dilinger@queued.net>
|
||||
|
||||
--------------------------
|
||||
|
||||
What: remove EXPORT_SYMBOL(kernel_thread)
|
||||
When: August 2006
|
||||
Files: arch/*/kernel/*_ksyms.c
|
||||
@ -232,6 +248,17 @@ Who: Zhang Rui <rui.zhang@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: CONFIG_ACPI_PROCFS_POWER
|
||||
When: 2.6.39
|
||||
Why: sysfs I/F for ACPI power devices, including AC and Battery,
|
||||
has been working in upstream kenrel since 2.6.24, Sep 2007.
|
||||
In 2.6.37, we make the sysfs I/F always built in and this option
|
||||
disabled by default.
|
||||
Remove this option and the ACPI power procfs interface in 2.6.39.
|
||||
Who: Zhang Rui <rui.zhang@intel.com>
|
||||
|
||||
---------------------------
|
||||
|
||||
What: /proc/acpi/button
|
||||
When: August 2007
|
||||
Why: /proc/acpi/button has been replaced by events to the input layer
|
||||
@ -330,14 +357,6 @@ Who: Dave Jones <davej@redhat.com>, Matthew Garrett <mjg@redhat.com>
|
||||
|
||||
-----------------------------
|
||||
|
||||
What: __do_IRQ all in one fits nothing interrupt handler
|
||||
When: 2.6.32
|
||||
Why: __do_IRQ was kept for easy migration to the type flow handlers.
|
||||
More than two years of migration time is enough.
|
||||
Who: Thomas Gleixner <tglx@linutronix.de>
|
||||
|
||||
-----------------------------
|
||||
|
||||
What: fakephp and associated sysfs files in /sys/bus/pci/slots/
|
||||
When: 2011
|
||||
Why: In 2.6.27, the semantics of /sys/bus/pci/slots was redefined to
|
||||
@ -554,3 +573,33 @@ Why: This is a legacy interface which have been replaced by a more
|
||||
Who: NeilBrown <neilb@suse.de>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: i2c_adapter.id
|
||||
When: June 2011
|
||||
Why: This field is deprecated. I2C device drivers shouldn't change their
|
||||
behavior based on the underlying I2C adapter. Instead, the I2C
|
||||
adapter driver should instantiate the I2C devices and provide the
|
||||
needed platform-specific information.
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: cancel_rearming_delayed_work[queue]()
|
||||
When: 2.6.39
|
||||
|
||||
Why: The functions have been superceded by cancel_delayed_work_sync()
|
||||
quite some time ago. The conversion is trivial and there is no
|
||||
in-kernel user left.
|
||||
Who: Tejun Heo <tj@kernel.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: Legacy, non-standard chassis intrusion detection interface.
|
||||
When: June 2011
|
||||
Why: The adm9240, w83792d and w83793 hardware monitoring drivers have
|
||||
legacy interfaces for chassis intrusion detection. A standard
|
||||
interface has been added to each driver, so the legacy interface
|
||||
can be removed.
|
||||
Who: Jean Delvare <khali@linux-fr.org>
|
||||
|
||||
----------------------------
|
||||
|
||||
@ -9,24 +9,30 @@ be able to use diff(1).
|
||||
|
||||
--------------------------- dentry_operations --------------------------
|
||||
prototypes:
|
||||
int (*d_revalidate)(struct dentry *, int);
|
||||
int (*d_hash) (struct dentry *, struct qstr *);
|
||||
int (*d_compare) (struct dentry *, struct qstr *, struct qstr *);
|
||||
int (*d_revalidate)(struct dentry *, struct nameidata *);
|
||||
int (*d_hash)(const struct dentry *, const struct inode *,
|
||||
struct qstr *);
|
||||
int (*d_compare)(const struct dentry *, const struct inode *,
|
||||
const struct dentry *, const struct inode *,
|
||||
unsigned int, const char *, const struct qstr *);
|
||||
int (*d_delete)(struct dentry *);
|
||||
void (*d_release)(struct dentry *);
|
||||
void (*d_iput)(struct dentry *, struct inode *);
|
||||
char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
|
||||
struct vfsmount *(*d_automount)(struct path *path);
|
||||
int (*d_manage)(struct dentry *, bool);
|
||||
|
||||
locking rules:
|
||||
none have BKL
|
||||
dcache_lock rename_lock ->d_lock may block
|
||||
d_revalidate: no no no yes
|
||||
d_hash no no no yes
|
||||
d_compare: no yes no no
|
||||
d_delete: yes no yes no
|
||||
d_release: no no no yes
|
||||
d_iput: no no no yes
|
||||
rename_lock ->d_lock may block rcu-walk
|
||||
d_revalidate: no no yes (ref-walk) maybe
|
||||
d_hash no no no maybe
|
||||
d_compare: yes no no maybe
|
||||
d_delete: no yes no no
|
||||
d_release: no no yes no
|
||||
d_iput: no no yes no
|
||||
d_dname: no no no no
|
||||
d_automount: no no yes no
|
||||
d_manage: no no yes (ref-walk) maybe
|
||||
|
||||
--------------------------- inode_operations ---------------------------
|
||||
prototypes:
|
||||
@ -42,18 +48,22 @@ ata *);
|
||||
int (*rename) (struct inode *, struct dentry *,
|
||||
struct inode *, struct dentry *);
|
||||
int (*readlink) (struct dentry *, char __user *,int);
|
||||
int (*follow_link) (struct dentry *, struct nameidata *);
|
||||
void * (*follow_link) (struct dentry *, struct nameidata *);
|
||||
void (*put_link) (struct dentry *, struct nameidata *, void *);
|
||||
void (*truncate) (struct inode *);
|
||||
int (*permission) (struct inode *, int, struct nameidata *);
|
||||
int (*permission) (struct inode *, int, unsigned int);
|
||||
int (*check_acl)(struct inode *, int, unsigned int);
|
||||
int (*setattr) (struct dentry *, struct iattr *);
|
||||
int (*getattr) (struct vfsmount *, struct dentry *, struct kstat *);
|
||||
int (*setxattr) (struct dentry *, const char *,const void *,size_t,int);
|
||||
ssize_t (*getxattr) (struct dentry *, const char *, void *, size_t);
|
||||
ssize_t (*listxattr) (struct dentry *, char *, size_t);
|
||||
int (*removexattr) (struct dentry *, const char *);
|
||||
void (*truncate_range)(struct inode *, loff_t, loff_t);
|
||||
int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len);
|
||||
|
||||
locking rules:
|
||||
all may block, none have BKL
|
||||
all may block
|
||||
i_mutex(inode)
|
||||
lookup: yes
|
||||
create: yes
|
||||
@ -66,19 +76,23 @@ rmdir: yes (both) (see below)
|
||||
rename: yes (all) (see below)
|
||||
readlink: no
|
||||
follow_link: no
|
||||
put_link: no
|
||||
truncate: yes (see below)
|
||||
setattr: yes
|
||||
permission: no
|
||||
permission: no (may not block if called in rcu-walk mode)
|
||||
check_acl: no
|
||||
getattr: no
|
||||
setxattr: yes
|
||||
getxattr: no
|
||||
listxattr: no
|
||||
removexattr: yes
|
||||
truncate_range: yes
|
||||
fiemap: no
|
||||
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
|
||||
victim.
|
||||
cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
|
||||
->truncate() is never called directly - it's a callback, not a
|
||||
method. It's called by vmtruncate() - library function normally used by
|
||||
method. It's called by vmtruncate() - deprecated library function used by
|
||||
->setattr(). Locking information above applies to that call (i.e. is
|
||||
inherited from ->setattr() - vmtruncate() is used when ATTR_SIZE had been
|
||||
passed).
|
||||
@ -91,7 +105,7 @@ prototypes:
|
||||
struct inode *(*alloc_inode)(struct super_block *sb);
|
||||
void (*destroy_inode)(struct inode *);
|
||||
void (*dirty_inode) (struct inode *);
|
||||
int (*write_inode) (struct inode *, int);
|
||||
int (*write_inode) (struct inode *, struct writeback_control *wbc);
|
||||
int (*drop_inode) (struct inode *);
|
||||
void (*evict_inode) (struct inode *);
|
||||
void (*put_super) (struct super_block *);
|
||||
@ -105,10 +119,10 @@ prototypes:
|
||||
int (*show_options)(struct seq_file *, struct vfsmount *);
|
||||
ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
|
||||
ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
|
||||
int (*bdev_try_to_free_page)(struct super_block*, struct page*, gfp_t);
|
||||
|
||||
locking rules:
|
||||
All may block [not true, see below]
|
||||
None have BKL
|
||||
s_umount
|
||||
alloc_inode:
|
||||
destroy_inode:
|
||||
@ -127,6 +141,7 @@ umount_begin: no
|
||||
show_options: no (namespace_sem)
|
||||
quota_read: no (see below)
|
||||
quota_write: no (see below)
|
||||
bdev_try_to_free_page: no (see below)
|
||||
|
||||
->statfs() has s_umount (shared) when called by ustat(2) (native or
|
||||
compat), but that's an accident of bad API; s_umount is used to pin
|
||||
@ -139,19 +154,25 @@ be the only ones operating on the quota file by the quota code (via
|
||||
dqio_sem) (unless an admin really wants to screw up something and
|
||||
writes to quota files with quotas on). For other details about locking
|
||||
see also dquot_operations section.
|
||||
->bdev_try_to_free_page is called from the ->releasepage handler of
|
||||
the block device inode. See there for more details.
|
||||
|
||||
--------------------------- file_system_type ---------------------------
|
||||
prototypes:
|
||||
int (*get_sb) (struct file_system_type *, int,
|
||||
const char *, void *, struct vfsmount *);
|
||||
struct dentry *(*mount) (struct file_system_type *, int,
|
||||
const char *, void *);
|
||||
void (*kill_sb) (struct super_block *);
|
||||
locking rules:
|
||||
may block BKL
|
||||
get_sb yes no
|
||||
kill_sb yes no
|
||||
may block
|
||||
get_sb yes
|
||||
mount yes
|
||||
kill_sb yes
|
||||
|
||||
->get_sb() returns error or 0 with locked superblock attached to the vfsmount
|
||||
(exclusive on ->s_umount).
|
||||
->mount() returns ERR_PTR or the root dentry.
|
||||
->kill_sb() takes a write-locked superblock, does all shutdown work on it,
|
||||
unlocks and drops the reference.
|
||||
|
||||
@ -173,28 +194,38 @@ prototypes:
|
||||
sector_t (*bmap)(struct address_space *, sector_t);
|
||||
int (*invalidatepage) (struct page *, unsigned long);
|
||||
int (*releasepage) (struct page *, int);
|
||||
void (*freepage)(struct page *);
|
||||
int (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
|
||||
loff_t offset, unsigned long nr_segs);
|
||||
int (*launder_page) (struct page *);
|
||||
int (*get_xip_mem)(struct address_space *, pgoff_t, int, void **,
|
||||
unsigned long *);
|
||||
int (*migratepage)(struct address_space *, struct page *, struct page *);
|
||||
int (*launder_page)(struct page *);
|
||||
int (*is_partially_uptodate)(struct page *, read_descriptor_t *, unsigned long);
|
||||
int (*error_remove_page)(struct address_space *, struct page *);
|
||||
|
||||
locking rules:
|
||||
All except set_page_dirty may block
|
||||
All except set_page_dirty and freepage may block
|
||||
|
||||
BKL PageLocked(page) i_mutex
|
||||
writepage: no yes, unlocks (see below)
|
||||
readpage: no yes, unlocks
|
||||
sync_page: no maybe
|
||||
writepages: no
|
||||
set_page_dirty no no
|
||||
readpages: no
|
||||
write_begin: no locks the page yes
|
||||
write_end: no yes, unlocks yes
|
||||
perform_write: no n/a yes
|
||||
bmap: no
|
||||
invalidatepage: no yes
|
||||
releasepage: no yes
|
||||
direct_IO: no
|
||||
launder_page: no yes
|
||||
PageLocked(page) i_mutex
|
||||
writepage: yes, unlocks (see below)
|
||||
readpage: yes, unlocks
|
||||
sync_page: maybe
|
||||
writepages:
|
||||
set_page_dirty no
|
||||
readpages:
|
||||
write_begin: locks the page yes
|
||||
write_end: yes, unlocks yes
|
||||
bmap:
|
||||
invalidatepage: yes
|
||||
releasepage: yes
|
||||
freepage: yes
|
||||
direct_IO:
|
||||
get_xip_mem: maybe
|
||||
migratepage: yes (both)
|
||||
launder_page: yes
|
||||
is_partially_uptodate: yes
|
||||
error_remove_page: yes
|
||||
|
||||
->write_begin(), ->write_end(), ->sync_page() and ->readpage()
|
||||
may be called from the request handler (/dev/loop).
|
||||
@ -274,9 +305,8 @@ under spinlock (it cannot block) and is sometimes called with the page
|
||||
not locked.
|
||||
|
||||
->bmap() is currently used by legacy ioctl() (FIBMAP) provided by some
|
||||
filesystems and by the swapper. The latter will eventually go away. All
|
||||
instances do not actually need the BKL. Please, keep it that way and don't
|
||||
breed new callers.
|
||||
filesystems and by the swapper. The latter will eventually go away. Please,
|
||||
keep it that way and don't breed new callers.
|
||||
|
||||
->invalidatepage() is called when the filesystem must attempt to drop
|
||||
some or all of the buffers from the page when it is being truncated. It
|
||||
@ -288,53 +318,44 @@ buffers from the page in preparation for freeing it. It returns zero to
|
||||
indicate that the buffers are (or may be) freeable. If ->releasepage is zero,
|
||||
the kernel assumes that the fs has no private interest in the buffers.
|
||||
|
||||
->freepage() is called when the kernel is done dropping the page
|
||||
from the page cache.
|
||||
|
||||
->launder_page() may be called prior to releasing a page if
|
||||
it is still found to be dirty. It returns zero if the page was successfully
|
||||
cleaned, or an error value if not. Note that in order to prevent the page
|
||||
getting mapped back in and redirtied, it needs to be kept locked
|
||||
across the entire operation.
|
||||
|
||||
Note: currently almost all instances of address_space methods are
|
||||
using BKL for internal serialization and that's one of the worst sources
|
||||
of contention. Normally they are calling library functions (in fs/buffer.c)
|
||||
and pass foo_get_block() as a callback (on local block-based filesystems,
|
||||
indeed). BKL is not needed for library stuff and is usually taken by
|
||||
foo_get_block(). It's an overkill, since block bitmaps can be protected by
|
||||
internal fs locking and real critical areas are much smaller than the areas
|
||||
filesystems protect now.
|
||||
|
||||
----------------------- file_lock_operations ------------------------------
|
||||
prototypes:
|
||||
void (*fl_insert)(struct file_lock *); /* lock insertion callback */
|
||||
void (*fl_remove)(struct file_lock *); /* lock removal callback */
|
||||
void (*fl_copy_lock)(struct file_lock *, struct file_lock *);
|
||||
void (*fl_release_private)(struct file_lock *);
|
||||
|
||||
|
||||
locking rules:
|
||||
BKL may block
|
||||
fl_insert: yes no
|
||||
fl_remove: yes no
|
||||
fl_copy_lock: yes no
|
||||
fl_release_private: yes yes
|
||||
file_lock_lock may block
|
||||
fl_copy_lock: yes no
|
||||
fl_release_private: maybe no
|
||||
|
||||
----------------------- lock_manager_operations ---------------------------
|
||||
prototypes:
|
||||
int (*fl_compare_owner)(struct file_lock *, struct file_lock *);
|
||||
void (*fl_notify)(struct file_lock *); /* unblock callback */
|
||||
int (*fl_grant)(struct file_lock *, struct file_lock *, int);
|
||||
void (*fl_release_private)(struct file_lock *);
|
||||
void (*fl_break)(struct file_lock *); /* break_lease callback */
|
||||
int (*fl_change)(struct file_lock **, int);
|
||||
|
||||
locking rules:
|
||||
BKL may block
|
||||
fl_compare_owner: yes no
|
||||
fl_notify: yes no
|
||||
fl_release_private: yes yes
|
||||
fl_break: yes no
|
||||
file_lock_lock may block
|
||||
fl_compare_owner: yes no
|
||||
fl_notify: yes no
|
||||
fl_grant: no no
|
||||
fl_release_private: maybe no
|
||||
fl_break: yes no
|
||||
fl_change yes no
|
||||
|
||||
Currently only NFSD and NLM provide instances of this class. None of the
|
||||
them block. If you have out-of-tree instances - please, show up. Locking
|
||||
in that area will change.
|
||||
--------------------------- buffer_head -----------------------------------
|
||||
prototypes:
|
||||
void (*b_end_io)(struct buffer_head *bh, int uptodate);
|
||||
@ -359,17 +380,17 @@ prototypes:
|
||||
void (*swap_slot_free_notify) (struct block_device *, unsigned long);
|
||||
|
||||
locking rules:
|
||||
BKL bd_mutex
|
||||
open: no yes
|
||||
release: no yes
|
||||
ioctl: no no
|
||||
compat_ioctl: no no
|
||||
direct_access: no no
|
||||
media_changed: no no
|
||||
unlock_native_capacity: no no
|
||||
revalidate_disk: no no
|
||||
getgeo: no no
|
||||
swap_slot_free_notify: no no (see below)
|
||||
bd_mutex
|
||||
open: yes
|
||||
release: yes
|
||||
ioctl: no
|
||||
compat_ioctl: no
|
||||
direct_access: no
|
||||
media_changed: no
|
||||
unlock_native_capacity: no
|
||||
revalidate_disk: no
|
||||
getgeo: no
|
||||
swap_slot_free_notify: no (see below)
|
||||
|
||||
media_changed, unlock_native_capacity and revalidate_disk are called only from
|
||||
check_disk_change().
|
||||
@ -408,34 +429,22 @@ prototypes:
|
||||
unsigned long (*get_unmapped_area)(struct file *, unsigned long,
|
||||
unsigned long, unsigned long, unsigned long);
|
||||
int (*check_flags)(int);
|
||||
int (*flock) (struct file *, int, struct file_lock *);
|
||||
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *,
|
||||
size_t, unsigned int);
|
||||
ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *,
|
||||
size_t, unsigned int);
|
||||
int (*setlease)(struct file *, long, struct file_lock **);
|
||||
long (*fallocate)(struct file *, int, loff_t, loff_t);
|
||||
};
|
||||
|
||||
locking rules:
|
||||
All may block.
|
||||
BKL
|
||||
llseek: no (see below)
|
||||
read: no
|
||||
aio_read: no
|
||||
write: no
|
||||
aio_write: no
|
||||
readdir: no
|
||||
poll: no
|
||||
unlocked_ioctl: no
|
||||
compat_ioctl: no
|
||||
mmap: no
|
||||
open: no
|
||||
flush: no
|
||||
release: no
|
||||
fsync: no (see below)
|
||||
aio_fsync: no
|
||||
fasync: no
|
||||
lock: yes
|
||||
readv: no
|
||||
writev: no
|
||||
sendfile: no
|
||||
sendpage: no
|
||||
get_unmapped_area: no
|
||||
check_flags: no
|
||||
All may block except for ->setlease.
|
||||
No VFS locks held on entry except for ->fsync and ->setlease.
|
||||
|
||||
->fsync() has i_mutex on inode.
|
||||
|
||||
->setlease has the file_list_lock held and must not sleep.
|
||||
|
||||
->llseek() locking has moved from llseek to the individual llseek
|
||||
implementations. If your fs is not using generic_file_llseek, you
|
||||
@ -445,17 +454,10 @@ mutex or just to use i_size_read() instead.
|
||||
Note: this does not protect the file->f_pos against concurrent modifications
|
||||
since this is something the userspace has to take care about.
|
||||
|
||||
Note: ext2_release() was *the* source of contention on fs-intensive
|
||||
loads and dropping BKL on ->release() helps to get rid of that (we still
|
||||
grab BKL for cases when we close a file that had been opened r/w, but that
|
||||
can and should be done using the internal locking with smaller critical areas).
|
||||
Current worst offender is ext2_get_block()...
|
||||
|
||||
->fasync() is called without BKL protection, and is responsible for
|
||||
maintaining the FASYNC bit in filp->f_flags. Most instances call
|
||||
fasync_helper(), which does that maintenance, so it's not normally
|
||||
something one needs to worry about. Return values > 0 will be mapped to
|
||||
zero in the VFS layer.
|
||||
->fasync() is responsible for maintaining the FASYNC bit in filp->f_flags.
|
||||
Most instances call fasync_helper(), which does that maintenance, so it's
|
||||
not normally something one needs to worry about. Return values > 0 will be
|
||||
mapped to zero in the VFS layer.
|
||||
|
||||
->readdir() and ->ioctl() on directories must be changed. Ideally we would
|
||||
move ->readdir() to inode_operations and use a separate method for directory
|
||||
@ -466,8 +468,6 @@ components. And there are other reasons why the current interface is a mess...
|
||||
->read on directories probably must go away - we should just enforce -EISDIR
|
||||
in sys_read() and friends.
|
||||
|
||||
->fsync() has i_mutex on inode.
|
||||
|
||||
--------------------------- dquot_operations -------------------------------
|
||||
prototypes:
|
||||
int (*write_dquot) (struct dquot *);
|
||||
@ -502,12 +502,12 @@ prototypes:
|
||||
int (*access)(struct vm_area_struct *, unsigned long, void*, int, int);
|
||||
|
||||
locking rules:
|
||||
BKL mmap_sem PageLocked(page)
|
||||
open: no yes
|
||||
close: no yes
|
||||
fault: no yes can return with page locked
|
||||
page_mkwrite: no yes can return with page locked
|
||||
access: no yes
|
||||
mmap_sem PageLocked(page)
|
||||
open: yes
|
||||
close: yes
|
||||
fault: yes can return with page locked
|
||||
page_mkwrite: yes can return with page locked
|
||||
access: yes
|
||||
|
||||
->fault() is called when a previously not present pte is about
|
||||
to be faulted in. The filesystem must find and return the page associated
|
||||
@ -534,6 +534,3 @@ VM_IO | VM_PFNMAP VMAs.
|
||||
|
||||
(if you break something or notice that it is broken and do not fix it yourself
|
||||
- at least put it here)
|
||||
|
||||
ipc/shm.c::shm_delete() - may need BKL.
|
||||
->read() and ->write() in many drivers are (probably) missing BKL.
|
||||
|
||||
@ -89,7 +89,7 @@ static ssize_t childless_storeme_write(struct childless *childless,
|
||||
char *p = (char *) page;
|
||||
|
||||
tmp = simple_strtoul(p, &p, 10);
|
||||
if (!p || (*p && (*p != '\n')))
|
||||
if ((*p != '\0') && (*p != '\n'))
|
||||
return -EINVAL;
|
||||
|
||||
if (tmp > INT_MAX)
|
||||
|
||||
@ -1,174 +0,0 @@
|
||||
RCU-based dcache locking model
|
||||
==============================
|
||||
|
||||
On many workloads, the most common operation on dcache is to look up a
|
||||
dentry, given a parent dentry and the name of the child. Typically,
|
||||
for every open(), stat() etc., the dentry corresponding to the
|
||||
pathname will be looked up by walking the tree starting with the first
|
||||
component of the pathname and using that dentry along with the next
|
||||
component to look up the next level and so on. Since it is a frequent
|
||||
operation for workloads like multiuser environments and web servers,
|
||||
it is important to optimize this path.
|
||||
|
||||
Prior to 2.5.10, dcache_lock was acquired in d_lookup and thus in
|
||||
every component during path look-up. Since 2.5.10 onwards, fast-walk
|
||||
algorithm changed this by holding the dcache_lock at the beginning and
|
||||
walking as many cached path component dentries as possible. This
|
||||
significantly decreases the number of acquisition of
|
||||
dcache_lock. However it also increases the lock hold time
|
||||
significantly and affects performance in large SMP machines. Since
|
||||
2.5.62 kernel, dcache has been using a new locking model that uses RCU
|
||||
to make dcache look-up lock-free.
|
||||
|
||||
The current dcache locking model is not very different from the
|
||||
existing dcache locking model. Prior to 2.5.62 kernel, dcache_lock
|
||||
protected the hash chain, d_child, d_alias, d_lru lists as well as
|
||||
d_inode and several other things like mount look-up. RCU-based changes
|
||||
affect only the way the hash chain is protected. For everything else
|
||||
the dcache_lock must be taken for both traversing as well as
|
||||
updating. The hash chain updates too take the dcache_lock. The
|
||||
significant change is the way d_lookup traverses the hash chain, it
|
||||
doesn't acquire the dcache_lock for this and rely on RCU to ensure
|
||||
that the dentry has not been *freed*.
|
||||
|
||||
|
||||
Dcache locking details
|
||||
======================
|
||||
|
||||
For many multi-user workloads, open() and stat() on files are very
|
||||
frequently occurring operations. Both involve walking of path names to
|
||||
find the dentry corresponding to the concerned file. In 2.4 kernel,
|
||||
dcache_lock was held during look-up of each path component. Contention
|
||||
and cache-line bouncing of this global lock caused significant
|
||||
scalability problems. With the introduction of RCU in Linux kernel,
|
||||
this was worked around by making the look-up of path components during
|
||||
path walking lock-free.
|
||||
|
||||
|
||||
Safe lock-free look-up of dcache hash table
|
||||
===========================================
|
||||
|
||||
Dcache is a complex data structure with the hash table entries also
|
||||
linked together in other lists. In 2.4 kernel, dcache_lock protected
|
||||
all the lists. We applied RCU only on hash chain walking. The rest of
|
||||
the lists are still protected by dcache_lock. Some of the important
|
||||
changes are :
|
||||
|
||||
1. The deletion from hash chain is done using hlist_del_rcu() macro
|
||||
which doesn't initialize next pointer of the deleted dentry and
|
||||
this allows us to walk safely lock-free while a deletion is
|
||||
happening.
|
||||
|
||||
2. Insertion of a dentry into the hash table is done using
|
||||
hlist_add_head_rcu() which take care of ordering the writes - the
|
||||
writes to the dentry must be visible before the dentry is
|
||||
inserted. This works in conjunction with hlist_for_each_rcu(),
|
||||
which has since been replaced by hlist_for_each_entry_rcu(), while
|
||||
walking the hash chain. The only requirement is that all
|
||||
initialization to the dentry must be done before
|
||||
hlist_add_head_rcu() since we don't have dcache_lock protection
|
||||
while traversing the hash chain. This isn't different from the
|
||||
existing code.
|
||||
|
||||
3. The dentry looked up without holding dcache_lock by cannot be
|
||||
returned for walking if it is unhashed. It then may have a NULL
|
||||
d_inode or other bogosity since RCU doesn't protect the other
|
||||
fields in the dentry. We therefore use a flag DCACHE_UNHASHED to
|
||||
indicate unhashed dentries and use this in conjunction with a
|
||||
per-dentry lock (d_lock). Once looked up without the dcache_lock,
|
||||
we acquire the per-dentry lock (d_lock) and check if the dentry is
|
||||
unhashed. If so, the look-up is failed. If not, the reference count
|
||||
of the dentry is increased and the dentry is returned.
|
||||
|
||||
4. Once a dentry is looked up, it must be ensured during the path walk
|
||||
for that component it doesn't go away. In pre-2.5.10 code, this was
|
||||
done holding a reference to the dentry. dcache_rcu does the same.
|
||||
In some sense, dcache_rcu path walking looks like the pre-2.5.10
|
||||
version.
|
||||
|
||||
5. All dentry hash chain updates must take the dcache_lock as well as
|
||||
the per-dentry lock in that order. dput() does this to ensure that
|
||||
a dentry that has just been looked up in another CPU doesn't get
|
||||
deleted before dget() can be done on it.
|
||||
|
||||
6. There are several ways to do reference counting of RCU protected
|
||||
objects. One such example is in ipv4 route cache where deferred
|
||||
freeing (using call_rcu()) is done as soon as the reference count
|
||||
goes to zero. This cannot be done in the case of dentries because
|
||||
tearing down of dentries require blocking (dentry_iput()) which
|
||||
isn't supported from RCU callbacks. Instead, tearing down of
|
||||
dentries happen synchronously in dput(), but actual freeing happens
|
||||
later when RCU grace period is over. This allows safe lock-free
|
||||
walking of the hash chains, but a matched dentry may have been
|
||||
partially torn down. The checking of DCACHE_UNHASHED flag with
|
||||
d_lock held detects such dentries and prevents them from being
|
||||
returned from look-up.
|
||||
|
||||
|
||||
Maintaining POSIX rename semantics
|
||||
==================================
|
||||
|
||||
Since look-up of dentries is lock-free, it can race against a
|
||||
concurrent rename operation. For example, during rename of file A to
|
||||
B, look-up of either A or B must succeed. So, if look-up of B happens
|
||||
after A has been removed from the hash chain but not added to the new
|
||||
hash chain, it may fail. Also, a comparison while the name is being
|
||||
written concurrently by a rename may result in false positive matches
|
||||
violating rename semantics. Issues related to race with rename are
|
||||
handled as described below :
|
||||
|
||||
1. Look-up can be done in two ways - d_lookup() which is safe from
|
||||
simultaneous renames and __d_lookup() which is not. If
|
||||
__d_lookup() fails, it must be followed up by a d_lookup() to
|
||||
correctly determine whether a dentry is in the hash table or
|
||||
not. d_lookup() protects look-ups using a sequence lock
|
||||
(rename_lock).
|
||||
|
||||
2. The name associated with a dentry (d_name) may be changed if a
|
||||
rename is allowed to happen simultaneously. To avoid memcmp() in
|
||||
__d_lookup() go out of bounds due to a rename and false positive
|
||||
comparison, the name comparison is done while holding the
|
||||
per-dentry lock. This prevents concurrent renames during this
|
||||
operation.
|
||||
|
||||
3. Hash table walking during look-up may move to a different bucket as
|
||||
the current dentry is moved to a different bucket due to rename.
|
||||
But we use hlists in dcache hash table and they are
|
||||
null-terminated. So, even if a dentry moves to a different bucket,
|
||||
hash chain walk will terminate. [with a list_head list, it may not
|
||||
since termination is when the list_head in the original bucket is
|
||||
reached]. Since we redo the d_parent check and compare name while
|
||||
holding d_lock, lock-free look-up will not race against d_move().
|
||||
|
||||
4. There can be a theoretical race when a dentry keeps coming back to
|
||||
original bucket due to double moves. Due to this look-up may
|
||||
consider that it has never moved and can end up in a infinite loop.
|
||||
But this is not any worse that theoretical livelocks we already
|
||||
have in the kernel.
|
||||
|
||||
|
||||
Important guidelines for filesystem developers related to dcache_rcu
|
||||
====================================================================
|
||||
|
||||
1. Existing dcache interfaces (pre-2.5.62) exported to filesystem
|
||||
don't change. Only dcache internal implementation changes. However
|
||||
filesystems *must not* delete from the dentry hash chains directly
|
||||
using the list macros like allowed earlier. They must use dcache
|
||||
APIs like d_drop() or __d_drop() depending on the situation.
|
||||
|
||||
2. d_flags is now protected by a per-dentry lock (d_lock). All access
|
||||
to d_flags must be protected by it.
|
||||
|
||||
3. For a hashed dentry, checking of d_count needs to be protected by
|
||||
d_lock.
|
||||
|
||||
|
||||
Papers and other documentation on dcache locking
|
||||
================================================
|
||||
|
||||
1. Scaling dcache with RCU (http://linuxjournal.com/article.php?sid=7124).
|
||||
|
||||
2. http://lse.sourceforge.net/locking/dcache/dcache.html
|
||||
|
||||
|
||||
|
||||
@ -457,6 +457,11 @@ ChangeLog
|
||||
|
||||
Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
|
||||
|
||||
2.1.30:
|
||||
- Fix writev() (it kept writing the first segment over and over again
|
||||
instead of moving onto subsequent segments).
|
||||
- Fix crash in ntfs_mft_record_alloc() when mapping the new extent mft
|
||||
record failed.
|
||||
2.1.29:
|
||||
- Fix a deadlock when mounting read-write.
|
||||
2.1.28:
|
||||
|
||||
382
Documentation/filesystems/path-lookup.txt
Normal file
382
Documentation/filesystems/path-lookup.txt
Normal file
@ -0,0 +1,382 @@
|
||||
Path walking and name lookup locking
|
||||
====================================
|
||||
|
||||
Path resolution is the finding a dentry corresponding to a path name string, by
|
||||
performing a path walk. Typically, for every open(), stat() etc., the path name
|
||||
will be resolved. Paths are resolved by walking the namespace tree, starting
|
||||
with the first component of the pathname (eg. root or cwd) with a known dentry,
|
||||
then finding the child of that dentry, which is named the next component in the
|
||||
path string. Then repeating the lookup from the child dentry and finding its
|
||||
child with the next element, and so on.
|
||||
|
||||
Since it is a frequent operation for workloads like multiuser environments and
|
||||
web servers, it is important to optimize this code.
|
||||
|
||||
Path walking synchronisation history:
|
||||
Prior to 2.5.10, dcache_lock was acquired in d_lookup (dcache hash lookup) and
|
||||
thus in every component during path look-up. Since 2.5.10 onwards, fast-walk
|
||||
algorithm changed this by holding the dcache_lock at the beginning and walking
|
||||
as many cached path component dentries as possible. This significantly
|
||||
decreases the number of acquisition of dcache_lock. However it also increases
|
||||
the lock hold time significantly and affects performance in large SMP machines.
|
||||
Since 2.5.62 kernel, dcache has been using a new locking model that uses RCU to
|
||||
make dcache look-up lock-free.
|
||||
|
||||
All the above algorithms required taking a lock and reference count on the
|
||||
dentry that was looked up, so that may be used as the basis for walking the
|
||||
next path element. This is inefficient and unscalable. It is inefficient
|
||||
because of the locks and atomic operations required for every dentry element
|
||||
slows things down. It is not scalable because many parallel applications that
|
||||
are path-walk intensive tend to do path lookups starting from a common dentry
|
||||
(usually, the root "/" or current working directory). So contention on these
|
||||
common path elements causes lock and cacheline queueing.
|
||||
|
||||
Since 2.6.38, RCU is used to make a significant part of the entire path walk
|
||||
(including dcache look-up) completely "store-free" (so, no locks, atomics, or
|
||||
even stores into cachelines of common dentries). This is known as "rcu-walk"
|
||||
path walking.
|
||||
|
||||
Path walking overview
|
||||
=====================
|
||||
|
||||
A name string specifies a start (root directory, cwd, fd-relative) and a
|
||||
sequence of elements (directory entry names), which together refer to a path in
|
||||
the namespace. A path is represented as a (dentry, vfsmount) tuple. The name
|
||||
elements are sub-strings, seperated by '/'.
|
||||
|
||||
Name lookups will want to find a particular path that a name string refers to
|
||||
(usually the final element, or parent of final element). This is done by taking
|
||||
the path given by the name's starting point (which we know in advance -- eg.
|
||||
current->fs->cwd or current->fs->root) as the first parent of the lookup. Then
|
||||
iteratively for each subsequent name element, look up the child of the current
|
||||
parent with the given name and if it is not the desired entry, make it the
|
||||
parent for the next lookup.
|
||||
|
||||
A parent, of course, must be a directory, and we must have appropriate
|
||||
permissions on the parent inode to be able to walk into it.
|
||||
|
||||
Turning the child into a parent for the next lookup requires more checks and
|
||||
procedures. Symlinks essentially substitute the symlink name for the target
|
||||
name in the name string, and require some recursive path walking. Mount points
|
||||
must be followed into (thus changing the vfsmount that subsequent path elements
|
||||
refer to), switching from the mount point path to the root of the particular
|
||||
mounted vfsmount. These behaviours are variously modified depending on the
|
||||
exact path walking flags.
|
||||
|
||||
Path walking then must, broadly, do several particular things:
|
||||
- find the start point of the walk;
|
||||
- perform permissions and validity checks on inodes;
|
||||
- perform dcache hash name lookups on (parent, name element) tuples;
|
||||
- traverse mount points;
|
||||
- traverse symlinks;
|
||||
- lookup and create missing parts of the path on demand.
|
||||
|
||||
Safe store-free look-up of dcache hash table
|
||||
============================================
|
||||
|
||||
Dcache name lookup
|
||||
------------------
|
||||
In order to lookup a dcache (parent, name) tuple, we take a hash on the tuple
|
||||
and use that to select a bucket in the dcache-hash table. The list of entries
|
||||
in that bucket is then walked, and we do a full comparison of each entry
|
||||
against our (parent, name) tuple.
|
||||
|
||||
The hash lists are RCU protected, so list walking is not serialised with
|
||||
concurrent updates (insertion, deletion from the hash). This is a standard RCU
|
||||
list application with the exception of renames, which will be covered below.
|
||||
|
||||
Parent and name members of a dentry, as well as its membership in the dcache
|
||||
hash, and its inode are protected by the per-dentry d_lock spinlock. A
|
||||
reference is taken on the dentry (while the fields are verified under d_lock),
|
||||
and this stabilises its d_inode pointer and actual inode. This gives a stable
|
||||
point to perform the next step of our path walk against.
|
||||
|
||||
These members are also protected by d_seq seqlock, although this offers
|
||||
read-only protection and no durability of results, so care must be taken when
|
||||
using d_seq for synchronisation (see seqcount based lookups, below).
|
||||
|
||||
Renames
|
||||
-------
|
||||
Back to the rename case. In usual RCU protected lists, the only operations that
|
||||
will happen to an object is insertion, and then eventually removal from the
|
||||
list. The object will not be reused until an RCU grace period is complete.
|
||||
This ensures the RCU list traversal primitives can run over the object without
|
||||
problems (see RCU documentation for how this works).
|
||||
|
||||
However when a dentry is renamed, its hash value can change, requiring it to be
|
||||
moved to a new hash list. Allocating and inserting a new alias would be
|
||||
expensive and also problematic for directory dentries. Latency would be far to
|
||||
high to wait for a grace period after removing the dentry and before inserting
|
||||
it in the new hash bucket. So what is done is to insert the dentry into the
|
||||
new list immediately.
|
||||
|
||||
However, when the dentry's list pointers are updated to point to objects in the
|
||||
new list before waiting for a grace period, this can result in a concurrent RCU
|
||||
lookup of the old list veering off into the new (incorrect) list and missing
|
||||
the remaining dentries on the list.
|
||||
|
||||
There is no fundamental problem with walking down the wrong list, because the
|
||||
dentry comparisons will never match. However it is fatal to miss a matching
|
||||
dentry. So a seqlock is used to detect when a rename has occurred, and so the
|
||||
lookup can be retried.
|
||||
|
||||
1 2 3
|
||||
+---+ +---+ +---+
|
||||
hlist-->| N-+->| N-+->| N-+->
|
||||
head <--+-P |<-+-P |<-+-P |
|
||||
+---+ +---+ +---+
|
||||
|
||||
Rename of dentry 2 may require it deleted from the above list, and inserted
|
||||
into a new list. Deleting 2 gives the following list.
|
||||
|
||||
1 3
|
||||
+---+ +---+ (don't worry, the longer pointers do not
|
||||
hlist-->| N-+-------->| N-+-> impose a measurable performance overhead
|
||||
head <--+-P |<--------+-P | on modern CPUs)
|
||||
+---+ +---+
|
||||
^ 2 ^
|
||||
| +---+ |
|
||||
| | N-+----+
|
||||
+----+-P |
|
||||
+---+
|
||||
|
||||
This is a standard RCU-list deletion, which leaves the deleted object's
|
||||
pointers intact, so a concurrent list walker that is currently looking at
|
||||
object 2 will correctly continue to object 3 when it is time to traverse the
|
||||
next object.
|
||||
|
||||
However, when inserting object 2 onto a new list, we end up with this:
|
||||
|
||||
1 3
|
||||
+---+ +---+
|
||||
hlist-->| N-+-------->| N-+->
|
||||
head <--+-P |<--------+-P |
|
||||
+---+ +---+
|
||||
2
|
||||
+---+
|
||||
| N-+---->
|
||||
<----+-P |
|
||||
+---+
|
||||
|
||||
Because we didn't wait for a grace period, there may be a concurrent lookup
|
||||
still at 2. Now when it follows 2's 'next' pointer, it will walk off into
|
||||
another list without ever having checked object 3.
|
||||
|
||||
A related, but distinctly different, issue is that of rename atomicity versus
|
||||
lookup operations. If a file is renamed from 'A' to 'B', a lookup must only
|
||||
find either 'A' or 'B'. So if a lookup of 'A' returns NULL, a subsequent lookup
|
||||
of 'B' must succeed (note the reverse is not true).
|
||||
|
||||
Between deleting the dentry from the old hash list, and inserting it on the new
|
||||
hash list, a lookup may find neither 'A' nor 'B' matching the dentry. The same
|
||||
rename seqlock is also used to cover this race in much the same way, by
|
||||
retrying a negative lookup result if a rename was in progress.
|
||||
|
||||
Seqcount based lookups
|
||||
----------------------
|
||||
In refcount based dcache lookups, d_lock is used to serialise access to
|
||||
the dentry, stabilising it while comparing its name and parent and then
|
||||
taking a reference count (the reference count then gives a stable place to
|
||||
start the next part of the path walk from).
|
||||
|
||||
As explained above, we would like to do path walking without taking locks or
|
||||
reference counts on intermediate dentries along the path. To do this, a per
|
||||
dentry seqlock (d_seq) is used to take a "coherent snapshot" of what the dentry
|
||||
looks like (its name, parent, and inode). That snapshot is then used to start
|
||||
the next part of the path walk. When loading the coherent snapshot under d_seq,
|
||||
care must be taken to load the members up-front, and use those pointers rather
|
||||
than reloading from the dentry later on (otherwise we'd have interesting things
|
||||
like d_inode going NULL underneath us, if the name was unlinked).
|
||||
|
||||
Also important is to avoid performing any destructive operations (pretty much:
|
||||
no non-atomic stores to shared data), and to recheck the seqcount when we are
|
||||
"done" with the operation. Retry or abort if the seqcount does not match.
|
||||
Avoiding destructive or changing operations means we can easily unwind from
|
||||
failure.
|
||||
|
||||
What this means is that a caller, provided they are holding RCU lock to
|
||||
protect the dentry object from disappearing, can perform a seqcount based
|
||||
lookup which does not increment the refcount on the dentry or write to
|
||||
it in any way. This returned dentry can be used for subsequent operations,
|
||||
provided that d_seq is rechecked after that operation is complete.
|
||||
|
||||
Inodes are also rcu freed, so the seqcount lookup dentry's inode may also be
|
||||
queried for permissions.
|
||||
|
||||
With this two parts of the puzzle, we can do path lookups without taking
|
||||
locks or refcounts on dentry elements.
|
||||
|
||||
RCU-walk path walking design
|
||||
============================
|
||||
|
||||
Path walking code now has two distinct modes, ref-walk and rcu-walk. ref-walk
|
||||
is the traditional[*] way of performing dcache lookups using d_lock to
|
||||
serialise concurrent modifications to the dentry and take a reference count on
|
||||
it. ref-walk is simple and obvious, and may sleep, take locks, etc while path
|
||||
walking is operating on each dentry. rcu-walk uses seqcount based dentry
|
||||
lookups, and can perform lookup of intermediate elements without any stores to
|
||||
shared data in the dentry or inode. rcu-walk can not be applied to all cases,
|
||||
eg. if the filesystem must sleep or perform non trivial operations, rcu-walk
|
||||
must be switched to ref-walk mode.
|
||||
|
||||
[*] RCU is still used for the dentry hash lookup in ref-walk, but not the full
|
||||
path walk.
|
||||
|
||||
Where ref-walk uses a stable, refcounted ``parent'' to walk the remaining
|
||||
path string, rcu-walk uses a d_seq protected snapshot. When looking up a
|
||||
child of this parent snapshot, we open d_seq critical section on the child
|
||||
before closing d_seq critical section on the parent. This gives an interlocking
|
||||
ladder of snapshots to walk down.
|
||||
|
||||
|
||||
proc 101
|
||||
/----------------\
|
||||
/ comm: "vi" \
|
||||
/ fs.root: dentry0 \
|
||||
\ fs.cwd: dentry2 /
|
||||
\ /
|
||||
\----------------/
|
||||
|
||||
So when vi wants to open("/home/npiggin/test.c", O_RDWR), then it will
|
||||
start from current->fs->root, which is a pinned dentry. Alternatively,
|
||||
"./test.c" would start from cwd; both names refer to the same path in
|
||||
the context of proc101.
|
||||
|
||||
dentry 0
|
||||
+---------------------+ rcu-walk begins here, we note d_seq, check the
|
||||
| name: "/" | inode's permission, and then look up the next
|
||||
| inode: 10 | path element which is "home"...
|
||||
| children:"home", ...|
|
||||
+---------------------+
|
||||
|
|
||||
dentry 1 V
|
||||
+---------------------+ ... which brings us here. We find dentry1 via
|
||||
| name: "home" | hash lookup, then note d_seq and compare name
|
||||
| inode: 678 | string and parent pointer. When we have a match,
|
||||
| children:"npiggin" | we now recheck the d_seq of dentry0. Then we
|
||||
+---------------------+ check inode and look up the next element.
|
||||
|
|
||||
dentry2 V
|
||||
+---------------------+ Note: if dentry0 is now modified, lookup is
|
||||
| name: "npiggin" | not necessarily invalid, so we need only keep a
|
||||
| inode: 543 | parent for d_seq verification, and grandparents
|
||||
| children:"a.c", ... | can be forgotten.
|
||||
+---------------------+
|
||||
|
|
||||
dentry3 V
|
||||
+---------------------+ At this point we have our destination dentry.
|
||||
| name: "a.c" | We now take its d_lock, verify d_seq of this
|
||||
| inode: 14221 | dentry. If that checks out, we can increment
|
||||
| children:NULL | its refcount because we're holding d_lock.
|
||||
+---------------------+
|
||||
|
||||
Taking a refcount on a dentry from rcu-walk mode, by taking its d_lock,
|
||||
re-checking its d_seq, and then incrementing its refcount is called
|
||||
"dropping rcu" or dropping from rcu-walk into ref-walk mode.
|
||||
|
||||
It is, in some sense, a bit of a house of cards. If the seqcount check of the
|
||||
parent snapshot fails, the house comes down, because we had closed the d_seq
|
||||
section on the grandparent, so we have nothing left to stand on. In that case,
|
||||
the path walk must be fully restarted (which we do in ref-walk mode, to avoid
|
||||
live locks). It is costly to have a full restart, but fortunately they are
|
||||
quite rare.
|
||||
|
||||
When we reach a point where sleeping is required, or a filesystem callout
|
||||
requires ref-walk, then instead of restarting the walk, we attempt to drop rcu
|
||||
at the last known good dentry we have. Avoiding a full restart in ref-walk in
|
||||
these cases is fundamental for performance and scalability because blocking
|
||||
operations such as creates and unlinks are not uncommon.
|
||||
|
||||
The detailed design for rcu-walk is like this:
|
||||
* LOOKUP_RCU is set in nd->flags, which distinguishes rcu-walk from ref-walk.
|
||||
* Take the RCU lock for the entire path walk, starting with the acquiring
|
||||
of the starting path (eg. root/cwd/fd-path). So now dentry refcounts are
|
||||
not required for dentry persistence.
|
||||
* synchronize_rcu is called when unregistering a filesystem, so we can
|
||||
access d_ops and i_ops during rcu-walk.
|
||||
* Similarly take the vfsmount lock for the entire path walk. So now mnt
|
||||
refcounts are not required for persistence. Also we are free to perform mount
|
||||
lookups, and to assume dentry mount points and mount roots are stable up and
|
||||
down the path.
|
||||
* Have a per-dentry seqlock to protect the dentry name, parent, and inode,
|
||||
so we can load this tuple atomically, and also check whether any of its
|
||||
members have changed.
|
||||
* Dentry lookups (based on parent, candidate string tuple) recheck the parent
|
||||
sequence after the child is found in case anything changed in the parent
|
||||
during the path walk.
|
||||
* inode is also RCU protected so we can load d_inode and use the inode for
|
||||
limited things.
|
||||
* i_mode, i_uid, i_gid can be tested for exec permissions during path walk.
|
||||
* i_op can be loaded.
|
||||
* When the destination dentry is reached, drop rcu there (ie. take d_lock,
|
||||
verify d_seq, increment refcount).
|
||||
* If seqlock verification fails anywhere along the path, do a full restart
|
||||
of the path lookup in ref-walk mode. -ECHILD tends to be used (for want of
|
||||
a better errno) to signal an rcu-walk failure.
|
||||
|
||||
The cases where rcu-walk cannot continue are:
|
||||
* NULL dentry (ie. any uncached path element)
|
||||
* Following links
|
||||
|
||||
It may be possible eventually to make following links rcu-walk aware.
|
||||
|
||||
Uncached path elements will always require dropping to ref-walk mode, at the
|
||||
very least because i_mutex needs to be grabbed, and objects allocated.
|
||||
|
||||
Final note:
|
||||
"store-free" path walking is not strictly store free. We take vfsmount lock
|
||||
and refcounts (both of which can be made per-cpu), and we also store to the
|
||||
stack (which is essentially CPU-local), and we also have to take locks and
|
||||
refcount on final dentry.
|
||||
|
||||
The point is that shared data, where practically possible, is not locked
|
||||
or stored into. The result is massive improvements in performance and
|
||||
scalability of path resolution.
|
||||
|
||||
|
||||
Interesting statistics
|
||||
======================
|
||||
|
||||
The following table gives rcu lookup statistics for a few simple workloads
|
||||
(2s12c24t Westmere, debian non-graphical system). Ungraceful are attempts to
|
||||
drop rcu that fail due to d_seq failure and requiring the entire path lookup
|
||||
again. Other cases are successful rcu-drops that are required before the final
|
||||
element, nodentry for missing dentry, revalidate for filesystem revalidate
|
||||
routine requiring rcu drop, permission for permission check requiring drop,
|
||||
and link for symlink traversal requiring drop.
|
||||
|
||||
rcu-lookups restart nodentry link revalidate permission
|
||||
bootup 47121 0 4624 1010 10283 7852
|
||||
dbench 25386793 0 6778659(26.7%) 55 549 1156
|
||||
kbuild 2696672 10 64442(2.3%) 108764(4.0%) 1 1590
|
||||
git diff 39605 0 28 2 0 106
|
||||
vfstest 24185492 4945 708725(2.9%) 1076136(4.4%) 0 2651
|
||||
|
||||
What this shows is that failed rcu-walk lookups, ie. ones that are restarted
|
||||
entirely with ref-walk, are quite rare. Even the "vfstest" case which
|
||||
specifically has concurrent renames/mkdir/rmdir/ creat/unlink/etc to excercise
|
||||
such races is not showing a huge amount of restarts.
|
||||
|
||||
Dropping from rcu-walk to ref-walk mean that we have encountered a dentry where
|
||||
the reference count needs to be taken for some reason. This is either because
|
||||
we have reached the target of the path walk, or because we have encountered a
|
||||
condition that can't be resolved in rcu-walk mode. Ideally, we drop rcu-walk
|
||||
only when we have reached the target dentry, so the other statistics show where
|
||||
this does not happen.
|
||||
|
||||
Note that a graceful drop from rcu-walk mode due to something such as the
|
||||
dentry not existing (which can be common) is not necessarily a failure of
|
||||
rcu-walk scheme, because some elements of the path may have been walked in
|
||||
rcu-walk mode. The further we get from common path elements (such as cwd or
|
||||
root), the less contended the dentry is likely to be. The closer we are to
|
||||
common path elements, the more likely they will exist in dentry cache.
|
||||
|
||||
|
||||
Papers and other documentation on dcache locking
|
||||
================================================
|
||||
|
||||
1. Scaling dcache with RCU (http://linuxjournal.com/article.php?sid=7124).
|
||||
|
||||
2. http://lse.sourceforge.net/locking/dcache/dcache.html
|
||||
|
||||
|
||||
@ -216,7 +216,6 @@ had ->revalidate()) add calls in ->follow_link()/->readlink().
|
||||
->d_parent changes are not protected by BKL anymore. Read access is safe
|
||||
if at least one of the following is true:
|
||||
* filesystem has no cross-directory rename()
|
||||
* dcache_lock is held
|
||||
* we know that parent had been locked (e.g. we are looking at
|
||||
->d_parent of ->lookup() argument).
|
||||
* we are called from ->rename().
|
||||
@ -318,3 +317,80 @@ if it's zero is not *and* *never* *had* *been* enough. Final unlink() and iput(
|
||||
may happen while the inode is in the middle of ->write_inode(); e.g. if you blindly
|
||||
free the on-disk inode, you may end up doing that while ->write_inode() is writing
|
||||
to it.
|
||||
|
||||
---
|
||||
[mandatory]
|
||||
|
||||
.d_delete() now only advises the dcache as to whether or not to cache
|
||||
unreferenced dentries, and is now only called when the dentry refcount goes to
|
||||
0. Even on 0 refcount transition, it must be able to tolerate being called 0,
|
||||
1, or more times (eg. constant, idempotent).
|
||||
|
||||
---
|
||||
[mandatory]
|
||||
|
||||
.d_compare() calling convention and locking rules are significantly
|
||||
changed. Read updated documentation in Documentation/filesystems/vfs.txt (and
|
||||
look at examples of other filesystems) for guidance.
|
||||
|
||||
---
|
||||
[mandatory]
|
||||
|
||||
.d_hash() calling convention and locking rules are significantly
|
||||
changed. Read updated documentation in Documentation/filesystems/vfs.txt (and
|
||||
look at examples of other filesystems) for guidance.
|
||||
|
||||
---
|
||||
[mandatory]
|
||||
dcache_lock is gone, replaced by fine grained locks. See fs/dcache.c
|
||||
for details of what locks to replace dcache_lock with in order to protect
|
||||
particular things. Most of the time, a filesystem only needs ->d_lock, which
|
||||
protects *all* the dcache state of a given dentry.
|
||||
|
||||
--
|
||||
[mandatory]
|
||||
|
||||
Filesystems must RCU-free their inodes, if they can have been accessed
|
||||
via rcu-walk path walk (basically, if the file can have had a path name in the
|
||||
vfs namespace).
|
||||
|
||||
i_dentry and i_rcu share storage in a union, and the vfs expects
|
||||
i_dentry to be reinitialized before it is freed, so an:
|
||||
|
||||
INIT_LIST_HEAD(&inode->i_dentry);
|
||||
|
||||
must be done in the RCU callback.
|
||||
|
||||
--
|
||||
[recommended]
|
||||
vfs now tries to do path walking in "rcu-walk mode", which avoids
|
||||
atomic operations and scalability hazards on dentries and inodes (see
|
||||
Documentation/filesystems/path-lookup.txt). d_hash and d_compare changes
|
||||
(above) are examples of the changes required to support this. For more complex
|
||||
filesystem callbacks, the vfs drops out of rcu-walk mode before the fs call, so
|
||||
no changes are required to the filesystem. However, this is costly and loses
|
||||
the benefits of rcu-walk mode. We will begin to add filesystem callbacks that
|
||||
are rcu-walk aware, shown below. Filesystems should take advantage of this
|
||||
where possible.
|
||||
|
||||
--
|
||||
[mandatory]
|
||||
d_revalidate is a callback that is made on every path element (if
|
||||
the filesystem provides it), which requires dropping out of rcu-walk mode. This
|
||||
may now be called in rcu-walk mode (nd->flags & LOOKUP_RCU). -ECHILD should be
|
||||
returned if the filesystem cannot handle rcu-walk. See
|
||||
Documentation/filesystems/vfs.txt for more details.
|
||||
|
||||
permission and check_acl are inode permission checks that are called
|
||||
on many or all directory inodes on the way down a path walk (to check for
|
||||
exec permission). These must now be rcu-walk aware (flags & IPERM_FLAG_RCU).
|
||||
See Documentation/filesystems/vfs.txt for more details.
|
||||
|
||||
--
|
||||
[mandatory]
|
||||
In ->fallocate() you must check the mode option passed in. If your
|
||||
filesystem does not support hole punching (deallocating space in the middle of a
|
||||
file) you must return -EOPNOTSUPP if FALLOC_FL_PUNCH_HOLE is set in mode.
|
||||
Currently you can only have FALLOC_FL_PUNCH_HOLE with FALLOC_FL_KEEP_SIZE set,
|
||||
so the i_size should not change when hole punching, even when puching the end of
|
||||
a file off.
|
||||
|
||||
@ -375,6 +375,7 @@ Anonymous: 0 kB
|
||||
Swap: 0 kB
|
||||
KernelPageSize: 4 kB
|
||||
MMUPageSize: 4 kB
|
||||
Locked: 374 kB
|
||||
|
||||
The first of these lines shows the same information as is displayed for the
|
||||
mapping in /proc/PID/maps. The remaining lines show the size of the mapping
|
||||
@ -670,6 +671,8 @@ varies by architecture and compile options. The following is from a
|
||||
|
||||
> cat /proc/meminfo
|
||||
|
||||
The "Locked" indicates whether the mapping is locked in memory or not.
|
||||
|
||||
|
||||
MemTotal: 16344972 kB
|
||||
MemFree: 13634064 kB
|
||||
@ -1181,6 +1184,30 @@ Table 1-12: Files in /proc/fs/ext4/<devname>
|
||||
mb_groups details of multiblock allocator buddy cache of free blocks
|
||||
..............................................................................
|
||||
|
||||
2.0 /proc/consoles
|
||||
------------------
|
||||
Shows registered system console lines.
|
||||
|
||||
To see which character device lines are currently used for the system console
|
||||
/dev/console, you may simply look into the file /proc/consoles:
|
||||
|
||||
> cat /proc/consoles
|
||||
tty0 -WU (ECp) 4:7
|
||||
ttyS0 -W- (Ep) 4:64
|
||||
|
||||
The columns are:
|
||||
|
||||
device name of the device
|
||||
operations R = can do read operations
|
||||
W = can do write operations
|
||||
U = can do unblank
|
||||
flags E = it is enabled
|
||||
C = it is prefered console
|
||||
B = it is primary boot console
|
||||
p = it is used for printk buffer
|
||||
b = it is not a TTY but a Braille device
|
||||
a = it is safe to use when cpu is offline
|
||||
major:minor major and minor number of the device separated by a colon
|
||||
|
||||
------------------------------------------------------------------------------
|
||||
Summary
|
||||
@ -1296,6 +1323,10 @@ scaled linearly with /proc/<pid>/oom_score_adj.
|
||||
Writing to /proc/<pid>/oom_score_adj or /proc/<pid>/oom_adj will change the
|
||||
other with its scaled value.
|
||||
|
||||
The value of /proc/<pid>/oom_score_adj may be reduced no lower than the last
|
||||
value set by a CAP_SYS_RESOURCE process. To reduce the value any lower
|
||||
requires CAP_SYS_RESOURCE.
|
||||
|
||||
NOTICE: /proc/<pid>/oom_adj is deprecated and will be removed, please see
|
||||
Documentation/feature-removal-schedule.txt.
|
||||
|
||||
|
||||
@ -325,7 +325,8 @@ struct inode_operations {
|
||||
void * (*follow_link) (struct dentry *, struct nameidata *);
|
||||
void (*put_link) (struct dentry *, struct nameidata *, void *);
|
||||
void (*truncate) (struct inode *);
|
||||
int (*permission) (struct inode *, int, struct nameidata *);
|
||||
int (*permission) (struct inode *, int, unsigned int);
|
||||
int (*check_acl)(struct inode *, int, unsigned int);
|
||||
int (*setattr) (struct dentry *, struct iattr *);
|
||||
int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *);
|
||||
int (*setxattr) (struct dentry *, const char *,const void *,size_t,int);
|
||||
@ -414,6 +415,13 @@ otherwise noted.
|
||||
permission: called by the VFS to check for access rights on a POSIX-like
|
||||
filesystem.
|
||||
|
||||
May be called in rcu-walk mode (flags & IPERM_FLAG_RCU). If in rcu-walk
|
||||
mode, the filesystem must check the permission without blocking or
|
||||
storing to the inode.
|
||||
|
||||
If a situation is encountered that rcu-walk cannot handle, return
|
||||
-ECHILD and it will be called again in ref-walk mode.
|
||||
|
||||
setattr: called by the VFS to set attributes for a file. This method
|
||||
is called by chmod(2) and related system calls.
|
||||
|
||||
@ -534,6 +542,7 @@ struct address_space_operations {
|
||||
sector_t (*bmap)(struct address_space *, sector_t);
|
||||
int (*invalidatepage) (struct page *, unsigned long);
|
||||
int (*releasepage) (struct page *, int);
|
||||
void (*freepage)(struct page *);
|
||||
ssize_t (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
|
||||
loff_t offset, unsigned long nr_segs);
|
||||
struct page* (*get_xip_page)(struct address_space *, sector_t,
|
||||
@ -660,11 +669,10 @@ struct address_space_operations {
|
||||
releasepage: releasepage is called on PagePrivate pages to indicate
|
||||
that the page should be freed if possible. ->releasepage
|
||||
should remove any private data from the page and clear the
|
||||
PagePrivate flag. It may also remove the page from the
|
||||
address_space. If this fails for some reason, it may indicate
|
||||
failure with a 0 return value.
|
||||
This is used in two distinct though related cases. The first
|
||||
is when the VM finds a clean page with no active users and
|
||||
PagePrivate flag. If releasepage() fails for some reason, it must
|
||||
indicate failure with a 0 return value.
|
||||
releasepage() is used in two distinct though related cases. The
|
||||
first is when the VM finds a clean page with no active users and
|
||||
wants to make it a free page. If ->releasepage succeeds, the
|
||||
page will be removed from the address_space and become free.
|
||||
|
||||
@ -679,6 +687,12 @@ struct address_space_operations {
|
||||
need to ensure this. Possibly it can clear the PageUptodate
|
||||
bit if it cannot free private data yet.
|
||||
|
||||
freepage: freepage is called once the page is no longer visible in
|
||||
the page cache in order to allow the cleanup of any private
|
||||
data. Since it may be called by the memory reclaimer, it
|
||||
should not assume that the original address_space mapping still
|
||||
exists, and it should not block.
|
||||
|
||||
direct_IO: called by the generic read/write routines to perform
|
||||
direct_IO - that is IO requests which bypass the page cache
|
||||
and transfer data directly between the storage and the
|
||||
@ -841,12 +855,17 @@ defined:
|
||||
|
||||
struct dentry_operations {
|
||||
int (*d_revalidate)(struct dentry *, struct nameidata *);
|
||||
int (*d_hash) (struct dentry *, struct qstr *);
|
||||
int (*d_compare) (struct dentry *, struct qstr *, struct qstr *);
|
||||
int (*d_delete)(struct dentry *);
|
||||
int (*d_hash)(const struct dentry *, const struct inode *,
|
||||
struct qstr *);
|
||||
int (*d_compare)(const struct dentry *, const struct inode *,
|
||||
const struct dentry *, const struct inode *,
|
||||
unsigned int, const char *, const struct qstr *);
|
||||
int (*d_delete)(const struct dentry *);
|
||||
void (*d_release)(struct dentry *);
|
||||
void (*d_iput)(struct dentry *, struct inode *);
|
||||
char *(*d_dname)(struct dentry *, char *, int);
|
||||
struct vfsmount *(*d_automount)(struct path *);
|
||||
int (*d_manage)(struct dentry *, bool, bool);
|
||||
};
|
||||
|
||||
d_revalidate: called when the VFS needs to revalidate a dentry. This
|
||||
@ -854,13 +873,45 @@ struct dentry_operations {
|
||||
dcache. Most filesystems leave this as NULL, because all their
|
||||
dentries in the dcache are valid
|
||||
|
||||
d_hash: called when the VFS adds a dentry to the hash table
|
||||
d_revalidate may be called in rcu-walk mode (nd->flags & LOOKUP_RCU).
|
||||
If in rcu-walk mode, the filesystem must revalidate the dentry without
|
||||
blocking or storing to the dentry, d_parent and d_inode should not be
|
||||
used without care (because they can go NULL), instead nd->inode should
|
||||
be used.
|
||||
|
||||
d_compare: called when a dentry should be compared with another
|
||||
If a situation is encountered that rcu-walk cannot handle, return
|
||||
-ECHILD and it will be called again in ref-walk mode.
|
||||
|
||||
d_delete: called when the last reference to a dentry is
|
||||
deleted. This means no-one is using the dentry, however it is
|
||||
still valid and in the dcache
|
||||
d_hash: called when the VFS adds a dentry to the hash table. The first
|
||||
dentry passed to d_hash is the parent directory that the name is
|
||||
to be hashed into. The inode is the dentry's inode.
|
||||
|
||||
Same locking and synchronisation rules as d_compare regarding
|
||||
what is safe to dereference etc.
|
||||
|
||||
d_compare: called to compare a dentry name with a given name. The first
|
||||
dentry is the parent of the dentry to be compared, the second is
|
||||
the parent's inode, then the dentry and inode (may be NULL) of the
|
||||
child dentry. len and name string are properties of the dentry to be
|
||||
compared. qstr is the name to compare it with.
|
||||
|
||||
Must be constant and idempotent, and should not take locks if
|
||||
possible, and should not or store into the dentry or inodes.
|
||||
Should not dereference pointers outside the dentry or inodes without
|
||||
lots of care (eg. d_parent, d_inode, d_name should not be used).
|
||||
|
||||
However, our vfsmount is pinned, and RCU held, so the dentries and
|
||||
inodes won't disappear, neither will our sb or filesystem module.
|
||||
->i_sb and ->d_sb may be used.
|
||||
|
||||
It is a tricky calling convention because it needs to be called under
|
||||
"rcu-walk", ie. without any locks or references on things.
|
||||
|
||||
d_delete: called when the last reference to a dentry is dropped and the
|
||||
dcache is deciding whether or not to cache it. Return 1 to delete
|
||||
immediately, or 0 to cache the dentry. Default is NULL which means to
|
||||
always cache a reachable dentry. d_delete must be constant and
|
||||
idempotent.
|
||||
|
||||
d_release: called when a dentry is really deallocated
|
||||
|
||||
@ -881,6 +932,47 @@ struct dentry_operations {
|
||||
at the end of the buffer, and returns a pointer to the first char.
|
||||
dynamic_dname() helper function is provided to take care of this.
|
||||
|
||||
d_automount: called when an automount dentry is to be traversed (optional).
|
||||
This should create a new VFS mount record and return the record to the
|
||||
caller. The caller is supplied with a path parameter giving the
|
||||
automount directory to describe the automount target and the parent
|
||||
VFS mount record to provide inheritable mount parameters. NULL should
|
||||
be returned if someone else managed to make the automount first. If
|
||||
the vfsmount creation failed, then an error code should be returned.
|
||||
If -EISDIR is returned, then the directory will be treated as an
|
||||
ordinary directory and returned to pathwalk to continue walking.
|
||||
|
||||
If a vfsmount is returned, the caller will attempt to mount it on the
|
||||
mountpoint and will remove the vfsmount from its expiration list in
|
||||
the case of failure. The vfsmount should be returned with 2 refs on
|
||||
it to prevent automatic expiration - the caller will clean up the
|
||||
additional ref.
|
||||
|
||||
This function is only used if DCACHE_NEED_AUTOMOUNT is set on the
|
||||
dentry. This is set by __d_instantiate() if S_AUTOMOUNT is set on the
|
||||
inode being added.
|
||||
|
||||
d_manage: called to allow the filesystem to manage the transition from a
|
||||
dentry (optional). This allows autofs, for example, to hold up clients
|
||||
waiting to explore behind a 'mountpoint' whilst letting the daemon go
|
||||
past and construct the subtree there. 0 should be returned to let the
|
||||
calling process continue. -EISDIR can be returned to tell pathwalk to
|
||||
use this directory as an ordinary directory and to ignore anything
|
||||
mounted on it and not to check the automount flag. Any other error
|
||||
code will abort pathwalk completely.
|
||||
|
||||
If the 'mounting_here' parameter is true, then namespace_sem is being
|
||||
held by the caller and the function should not initiate any mounts or
|
||||
unmounts that it will then wait for.
|
||||
|
||||
If the 'rcu_walk' parameter is true, then the caller is doing a
|
||||
pathwalk in RCU-walk mode. Sleeping is not permitted in this mode,
|
||||
and the caller can be asked to leave it and call again by returing
|
||||
-ECHILD.
|
||||
|
||||
This function is only used if DCACHE_MANAGE_TRANSIT is set on the
|
||||
dentry being transited from.
|
||||
|
||||
Example :
|
||||
|
||||
static char *pipefs_dname(struct dentry *dent, char *buffer, int buflen)
|
||||
@ -904,14 +996,11 @@ manipulate dentries:
|
||||
the usage count)
|
||||
|
||||
dput: close a handle for a dentry (decrements the usage count). If
|
||||
the usage count drops to 0, the "d_delete" method is called
|
||||
and the dentry is placed on the unused list if the dentry is
|
||||
still in its parents hash list. Putting the dentry on the
|
||||
unused list just means that if the system needs some RAM, it
|
||||
goes through the unused list of dentries and deallocates them.
|
||||
If the dentry has already been unhashed and the usage count
|
||||
drops to 0, in this case the dentry is deallocated after the
|
||||
"d_delete" method is called
|
||||
the usage count drops to 0, and the dentry is still in its
|
||||
parent's hash, the "d_delete" method is called to check whether
|
||||
it should be cached. If it should not be cached, or if the dentry
|
||||
is not hashed, it is deleted. Otherwise cached dentries are put
|
||||
into an LRU list to be reclaimed on memory shortage.
|
||||
|
||||
d_drop: this unhashes a dentry from its parents hash list. A
|
||||
subsequent call to dput() will deallocate the dentry if its
|
||||
|
||||
@ -794,17 +794,6 @@ designed.
|
||||
|
||||
Roadmap:
|
||||
|
||||
2.6.37 Remove experimental tag from mount option
|
||||
=> should be roughly 6 months after initial merge
|
||||
=> enough time to:
|
||||
=> gain confidence and fix problems reported by early
|
||||
adopters (a.k.a. guinea pigs)
|
||||
=> address worst performance regressions and undesired
|
||||
behaviours
|
||||
=> start tuning/optimising code for parallelism
|
||||
=> start tuning/optimising algorithms consuming
|
||||
excessive CPU time
|
||||
|
||||
2.6.39 Switch default mount option to use delayed logging
|
||||
=> should be roughly 12 months after initial merge
|
||||
=> enough time to shake out remaining problems before next round of
|
||||
|
||||
@ -617,6 +617,16 @@ and have the following read/write attributes:
|
||||
is configured as an output, this value may be written;
|
||||
any nonzero value is treated as high.
|
||||
|
||||
If the pin can be configured as interrupt-generating interrupt
|
||||
and if it has been configured to generate interrupts (see the
|
||||
description of "edge"), you can poll(2) on that file and
|
||||
poll(2) will return whenever the interrupt was triggered. If
|
||||
you use poll(2), set the events POLLPRI and POLLERR. If you
|
||||
use select(2), set the file descriptor in exceptfds. After
|
||||
poll(2) returns, either lseek(2) to the beginning of the sysfs
|
||||
file and read the new value or close the file and re-open it
|
||||
to read the value.
|
||||
|
||||
"edge" ... reads as either "none", "rising", "falling", or
|
||||
"both". Write these strings to select the signal edge(s)
|
||||
that will make poll(2) on the "value" file return.
|
||||
|
||||
@ -155,7 +155,7 @@ connected to a normally open switch.
|
||||
The ADM9240 provides an internal open drain on this line, and may output
|
||||
a 20 ms active low pulse to reset an external Chassis Intrusion latch.
|
||||
|
||||
Clear the CI latch by writing value 1 to the sysfs chassis_clear file.
|
||||
Clear the CI latch by writing value 0 to the sysfs intrusion0_alarm file.
|
||||
|
||||
Alarm flags reported as 16-bit word
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ Supported chips:
|
||||
http://focus.ti.com/lit/ds/symlink/ads7828.pdf
|
||||
|
||||
Authors:
|
||||
Steve Hardy <steve@linuxrealtime.co.uk>
|
||||
Steve Hardy <shardy@redhat.com>
|
||||
|
||||
Module Parameters
|
||||
-----------------
|
||||
|
||||
@ -42,7 +42,7 @@ Description
|
||||
This driver implements support for the hardware monitoring capabilities of the
|
||||
SMSC DME1737 and Asus A8000 (which are the same), SMSC SCH5027, SCH311x,
|
||||
and SCH5127 Super-I/O chips. These chips feature monitoring of 3 temp sensors
|
||||
temp[1-3] (2 remote diodes and 1 internal), 7 voltages in[0-6] (6 external and
|
||||
temp[1-3] (2 remote diodes and 1 internal), 8 voltages in[0-7] (7 external and
|
||||
1 internal) and up to 6 fan speeds fan[1-6]. Additionally, the chips implement
|
||||
up to 5 PWM outputs pwm[1-3,5-6] for controlling fan speeds both manually and
|
||||
automatically.
|
||||
@ -105,6 +105,7 @@ SCH5127:
|
||||
in4: V1_IN 0V - 1.5V
|
||||
in5: VTR (+3.3V standby) 0V - 4.38V
|
||||
in6: Vbat (+3.0V) 0V - 4.38V
|
||||
in7: Vtrip (+1.5V) 0V - 1.99V
|
||||
|
||||
Each voltage input has associated min and max limits which trigger an alarm
|
||||
when crossed.
|
||||
@ -217,10 +218,10 @@ cpu0_vid RO CPU core reference voltage in
|
||||
vrm RW Voltage regulator module version
|
||||
number.
|
||||
|
||||
in[0-6]_input RO Measured voltage in millivolts.
|
||||
in[0-6]_min RW Low limit for voltage input.
|
||||
in[0-6]_max RW High limit for voltage input.
|
||||
in[0-6]_alarm RO Voltage input alarm. Returns 1 if
|
||||
in[0-7]_input RO Measured voltage in millivolts.
|
||||
in[0-7]_min RW Low limit for voltage input.
|
||||
in[0-7]_max RW High limit for voltage input.
|
||||
in[0-7]_alarm RO Voltage input alarm. Returns 1 if
|
||||
voltage input is or went outside the
|
||||
associated min-max range, 0 otherwise.
|
||||
|
||||
@ -324,3 +325,4 @@ fan5 opt opt
|
||||
pwm5 opt opt
|
||||
fan6 opt opt
|
||||
pwm6 opt opt
|
||||
in7 yes
|
||||
|
||||
34
Documentation/hwmon/ds620
Normal file
34
Documentation/hwmon/ds620
Normal file
@ -0,0 +1,34 @@
|
||||
Kernel driver ds620
|
||||
===================
|
||||
|
||||
Supported chips:
|
||||
* Dallas Semiconductor DS620
|
||||
Prefix: 'ds620'
|
||||
Datasheet: Publicly available at the Dallas Semiconductor website
|
||||
http://www.dalsemi.com/
|
||||
|
||||
Authors:
|
||||
Roland Stigge <stigge@antcom.de>
|
||||
based on ds1621.c by
|
||||
Christian W. Zuckschwerdt <zany@triq.net>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The DS620 is a (one instance) digital thermometer and thermostat. It has both
|
||||
high and low temperature limits which can be user defined (i.e. programmed
|
||||
into non-volatile on-chip registers). Temperature range is -55 degree Celsius
|
||||
to +125. Between 0 and 70 degree Celsius, accuracy is 0.5 Kelvin. The value
|
||||
returned via sysfs displays post decimal positions.
|
||||
|
||||
The thermostat function works as follows: When configured via platform_data
|
||||
(struct ds620_platform_data) .pomode == 0 (default), the thermostat output pin
|
||||
PO is always low. If .pomode == 1, the thermostat is in PO_LOW mode. I.e., the
|
||||
output pin PO becomes active when the temperature falls below temp1_min and
|
||||
stays active until the temperature goes above temp1_max.
|
||||
|
||||
Likewise, with .pomode == 2, the thermostat is in PO_HIGH mode. I.e., the PO
|
||||
output pin becomes active when the temperature goes above temp1_max and stays
|
||||
active until the temperature falls below temp1_min.
|
||||
|
||||
The PO output pin of the DS620 operates active-low.
|
||||
@ -6,12 +6,16 @@ Supported chips:
|
||||
Prefix 'lm93'
|
||||
Addresses scanned: I2C 0x2c-0x2e
|
||||
Datasheet: http://www.national.com/ds.cgi/LM/LM93.pdf
|
||||
* National Semiconductor LM94
|
||||
Prefix 'lm94'
|
||||
Addresses scanned: I2C 0x2c-0x2e
|
||||
Datasheet: http://www.national.com/ds.cgi/LM/LM94.pdf
|
||||
|
||||
Authors:
|
||||
Mark M. Hoffman <mhoffman@lightlink.com>
|
||||
Ported to 2.6 by Eric J. Bowersox <ericb@aspsys.com>
|
||||
Adapted to 2.6.20 by Carsten Emde <ce@osadl.org>
|
||||
Modified for mainline integration by Hans J. Koch <hjk@linutronix.de>
|
||||
Modified for mainline integration by Hans J. Koch <hjk@hansjkoch.de>
|
||||
|
||||
Module Parameters
|
||||
-----------------
|
||||
@ -56,6 +60,9 @@ previous motherboard management ASICs and uses some of the LM85's features
|
||||
for dynamic Vccp monitoring and PROCHOT. It is designed to monitor a dual
|
||||
processor Xeon class motherboard with a minimum of external components.
|
||||
|
||||
LM94 is also supported in LM93 compatible mode. Extra sensors and features of
|
||||
LM94 are not supported.
|
||||
|
||||
|
||||
User Interface
|
||||
--------------
|
||||
|
||||
@ -8,7 +8,7 @@ Supported chips:
|
||||
Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf
|
||||
|
||||
Authors:
|
||||
Hans J. Koch <hjk@linutronix.de>
|
||||
Hans J. Koch <hjk@hansjkoch.de>
|
||||
John Morris <john.morris@spirentcom.com>
|
||||
Claus Gindhart <claus.gindhart@kontron.com>
|
||||
|
||||
|
||||
49
Documentation/hwmon/sht21
Normal file
49
Documentation/hwmon/sht21
Normal file
@ -0,0 +1,49 @@
|
||||
Kernel driver sht21
|
||||
===================
|
||||
|
||||
Supported chips:
|
||||
* Sensirion SHT21
|
||||
Prefix: 'sht21'
|
||||
Addresses scanned: none
|
||||
Datasheet: Publicly available at the Sensirion website
|
||||
http://www.sensirion.com/en/pdf/product_information/Datasheet-humidity-sensor-SHT21.pdf
|
||||
|
||||
* Sensirion SHT25
|
||||
Prefix: 'sht21'
|
||||
Addresses scanned: none
|
||||
Datasheet: Publicly available at the Sensirion website
|
||||
http://www.sensirion.com/en/pdf/product_information/Datasheet-humidity-sensor-SHT25.pdf
|
||||
|
||||
Author:
|
||||
Urs Fleisch <urs.fleisch@sensirion.com>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
The SHT21 and SHT25 are humidity and temperature sensors in a DFN package of
|
||||
only 3 x 3 mm footprint and 1.1 mm height. The difference between the two
|
||||
devices is the higher level of precision of the SHT25 (1.8% relative humidity,
|
||||
0.2 degree Celsius) compared with the SHT21 (2.0% relative humidity,
|
||||
0.3 degree Celsius).
|
||||
|
||||
The devices communicate with the I2C protocol. All sensors are set to the same
|
||||
I2C address 0x40, so an entry with I2C_BOARD_INFO("sht21", 0x40) can be used
|
||||
in the board setup code.
|
||||
|
||||
sysfs-Interface
|
||||
---------------
|
||||
|
||||
temp1_input - temperature input
|
||||
humidity1_input - humidity input
|
||||
|
||||
Notes
|
||||
-----
|
||||
|
||||
The driver uses the default resolution settings of 12 bit for humidity and 14
|
||||
bit for temperature, which results in typical measurement times of 22 ms for
|
||||
humidity and 66 ms for temperature. To keep self heating below 0.1 degree
|
||||
Celsius, the device should not be active for more than 10% of the time,
|
||||
e.g. maximum two measurements per second at the given resolution.
|
||||
|
||||
Different resolutions, the on-chip heater, using the CRC checksum and reading
|
||||
the serial number are not supported yet.
|
||||
@ -384,10 +384,20 @@ curr[1-*]_min Current min value.
|
||||
Unit: milliampere
|
||||
RW
|
||||
|
||||
curr[1-*]_lcrit Current critical low value
|
||||
Unit: milliampere
|
||||
RW
|
||||
|
||||
curr[1-*]_crit Current critical high value.
|
||||
Unit: milliampere
|
||||
RW
|
||||
|
||||
curr[1-*]_input Current input value
|
||||
Unit: milliampere
|
||||
RO
|
||||
|
||||
Also see the Alarms section for status flags associated with currents.
|
||||
|
||||
*********
|
||||
* Power *
|
||||
*********
|
||||
@ -450,13 +460,6 @@ power[1-*]_accuracy Accuracy of the power meter.
|
||||
Unit: Percent
|
||||
RO
|
||||
|
||||
power[1-*]_alarm 1 if the system is drawing more power than the
|
||||
cap allows; 0 otherwise. A poll notification is
|
||||
sent to this file when the power use exceeds the
|
||||
cap. This file only appears if the cap is known
|
||||
to be enforced by hardware.
|
||||
RO
|
||||
|
||||
power[1-*]_cap If power use rises above this limit, the
|
||||
system should take action to reduce power use.
|
||||
A poll notification is sent to this file if the
|
||||
@ -479,6 +482,20 @@ power[1-*]_cap_min Minimum cap that can be set.
|
||||
Unit: microWatt
|
||||
RO
|
||||
|
||||
power[1-*]_max Maximum power.
|
||||
Unit: microWatt
|
||||
RW
|
||||
|
||||
power[1-*]_crit Critical maximum power.
|
||||
If power rises to or above this limit, the
|
||||
system is expected take drastic action to reduce
|
||||
power consumption, such as a system shutdown or
|
||||
a forced powerdown of some devices.
|
||||
Unit: microWatt
|
||||
RW
|
||||
|
||||
Also see the Alarms section for status flags associated with power readings.
|
||||
|
||||
**********
|
||||
* Energy *
|
||||
**********
|
||||
@ -488,6 +505,15 @@ energy[1-*]_input Cumulative energy use
|
||||
RO
|
||||
|
||||
|
||||
************
|
||||
* Humidity *
|
||||
************
|
||||
|
||||
humidity[1-*]_input Humidity
|
||||
Unit: milli-percent (per cent mille, pcm)
|
||||
RO
|
||||
|
||||
|
||||
**********
|
||||
* Alarms *
|
||||
**********
|
||||
@ -501,6 +527,7 @@ implementation.
|
||||
|
||||
in[0-*]_alarm
|
||||
curr[1-*]_alarm
|
||||
power[1-*]_alarm
|
||||
fan[1-*]_alarm
|
||||
temp[1-*]_alarm
|
||||
Channel alarm
|
||||
@ -512,12 +539,20 @@ OR
|
||||
|
||||
in[0-*]_min_alarm
|
||||
in[0-*]_max_alarm
|
||||
in[0-*]_lcrit_alarm
|
||||
in[0-*]_crit_alarm
|
||||
curr[1-*]_min_alarm
|
||||
curr[1-*]_max_alarm
|
||||
curr[1-*]_lcrit_alarm
|
||||
curr[1-*]_crit_alarm
|
||||
power[1-*]_cap_alarm
|
||||
power[1-*]_max_alarm
|
||||
power[1-*]_crit_alarm
|
||||
fan[1-*]_min_alarm
|
||||
fan[1-*]_max_alarm
|
||||
temp[1-*]_min_alarm
|
||||
temp[1-*]_max_alarm
|
||||
temp[1-*]_lcrit_alarm
|
||||
temp[1-*]_crit_alarm
|
||||
temp[1-*]_emergency_alarm
|
||||
Limit alarm
|
||||
|
||||
@ -91,3 +91,25 @@ isaset -y -f 0x2e 0xaa
|
||||
|
||||
The above sequence assumes a Super-I/O config space at 0x2e/0x2f, but
|
||||
0x4e/0x4f is also possible.
|
||||
|
||||
Voltage pin mapping
|
||||
-------------------
|
||||
|
||||
Here is a summary of the voltage pin mapping for the W83627THF. This
|
||||
can be useful to convert data provided by board manufacturers into
|
||||
working libsensors configuration statements.
|
||||
|
||||
W83627THF |
|
||||
Pin | Name | Register | Sysfs attribute
|
||||
-----------------------------------------------------
|
||||
100 | CPUVCORE | 20h | in0
|
||||
99 | VIN0 | 21h | in1
|
||||
98 | VIN1 | 22h | in2
|
||||
97 | VIN2 | 24h | in4
|
||||
114 | AVCC | 23h | in3
|
||||
61 | 5VSB | 50h (bank 5) | in7
|
||||
74 | VBAT | 51h (bank 5) | in8
|
||||
|
||||
For other supported devices, you'll have to take the hard path and
|
||||
look up the information in the datasheet yourself (and then add it
|
||||
to this document please.)
|
||||
|
||||
@ -92,7 +92,7 @@ This driver implements support for Winbond W83793G/W83793R chips.
|
||||
|
||||
* Chassis
|
||||
If the case open alarm triggers, it will stay in this state unless cleared
|
||||
by any write to the sysfs file "chassis".
|
||||
by writing 0 to the sysfs file "intrusion0_alarm".
|
||||
|
||||
* VID and VRM
|
||||
The VRM version is detected automatically, don't modify the it unless you
|
||||
|
||||
65
Documentation/i2c/muxes/gpio-i2cmux
Normal file
65
Documentation/i2c/muxes/gpio-i2cmux
Normal file
@ -0,0 +1,65 @@
|
||||
Kernel driver gpio-i2cmux
|
||||
|
||||
Author: Peter Korsgaard <peter.korsgaard@barco.com>
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
gpio-i2cmux is an i2c mux driver providing access to I2C bus segments
|
||||
from a master I2C bus and a hardware MUX controlled through GPIO pins.
|
||||
|
||||
E.G.:
|
||||
|
||||
---------- ---------- Bus segment 1 - - - - -
|
||||
| | SCL/SDA | |-------------- | |
|
||||
| |------------| |
|
||||
| | | | Bus segment 2 | |
|
||||
| Linux | GPIO 1..N | MUX |--------------- Devices
|
||||
| |------------| | | |
|
||||
| | | | Bus segment M
|
||||
| | | |---------------| |
|
||||
---------- ---------- - - - - -
|
||||
|
||||
SCL/SDA of the master I2C bus is multiplexed to bus segment 1..M
|
||||
according to the settings of the GPIO pins 1..N.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
gpio-i2cmux uses the platform bus, so you need to provide a struct
|
||||
platform_device with the platform_data pointing to a struct
|
||||
gpio_i2cmux_platform_data with the I2C adapter number of the master
|
||||
bus, the number of bus segments to create and the GPIO pins used
|
||||
to control it. See include/linux/gpio-i2cmux.h for details.
|
||||
|
||||
E.G. something like this for a MUX providing 4 bus segments
|
||||
controlled through 3 GPIO pins:
|
||||
|
||||
#include <linux/gpio-i2cmux.h>
|
||||
#include <linux/platform_device.h>
|
||||
|
||||
static const unsigned myboard_gpiomux_gpios[] = {
|
||||
AT91_PIN_PC26, AT91_PIN_PC25, AT91_PIN_PC24
|
||||
};
|
||||
|
||||
static const unsigned myboard_gpiomux_values[] = {
|
||||
0, 1, 2, 3
|
||||
};
|
||||
|
||||
static struct gpio_i2cmux_platform_data myboard_i2cmux_data = {
|
||||
.parent = 1,
|
||||
.base_nr = 2, /* optional */
|
||||
.values = myboard_gpiomux_values,
|
||||
.n_values = ARRAY_SIZE(myboard_gpiomux_values),
|
||||
.gpios = myboard_gpiomux_gpios,
|
||||
.n_gpios = ARRAY_SIZE(myboard_gpiomux_gpios),
|
||||
.idle = 4, /* optional */
|
||||
};
|
||||
|
||||
static struct platform_device myboard_i2cmux = {
|
||||
.name = "gpio-i2cmux",
|
||||
.id = 0,
|
||||
.dev = {
|
||||
.platform_data = &myboard_i2cmux_data,
|
||||
},
|
||||
};
|
||||
@ -155,7 +155,6 @@ Code Seq#(hex) Include File Comments
|
||||
'Q' all linux/soundcard.h
|
||||
'R' 00-1F linux/random.h conflict!
|
||||
'R' 01 linux/rfkill.h conflict!
|
||||
'R' 01-0F media/rds.h conflict!
|
||||
'R' C0-DF net/bluetooth/rfcomm.h
|
||||
'S' all linux/cdrom.h conflict!
|
||||
'S' 80-81 scsi/scsi_ioctl.h conflict!
|
||||
@ -194,7 +193,6 @@ Code Seq#(hex) Include File Comments
|
||||
<http://lrcwww.epfl.ch/>
|
||||
'b' 00-FF conflict! bit3 vme host bridge
|
||||
<mailto:natalia@nikhefk.nikhef.nl>
|
||||
'b' 00-0F media/bt819.h conflict!
|
||||
'c' all linux/cm4000_cs.h conflict!
|
||||
'c' 00-7F linux/comstats.h conflict!
|
||||
'c' 00-7F linux/coda.h conflict!
|
||||
@ -249,7 +247,7 @@ Code Seq#(hex) Include File Comments
|
||||
'p' 40-7F linux/nvram.h
|
||||
'p' 80-9F linux/ppdev.h user-space parport
|
||||
<mailto:tim@cyberelk.net>
|
||||
'p' A1-A4 linux/pps.h LinuxPPS
|
||||
'p' A1-A5 linux/pps.h LinuxPPS
|
||||
<mailto:giometti@linux.it>
|
||||
'q' 00-1F linux/serio.h
|
||||
'q' 80-FF linux/telephony.h Internet PhoneJACK, Internet LineJACK
|
||||
@ -260,14 +258,11 @@ Code Seq#(hex) Include File Comments
|
||||
't' 80-8F linux/isdn_ppp.h
|
||||
't' 90 linux/toshiba.h
|
||||
'u' 00-1F linux/smb_fs.h gone
|
||||
'v' all linux/videodev.h conflict!
|
||||
'v' 00-1F linux/ext2_fs.h conflict!
|
||||
'v' 00-1F linux/fs.h conflict!
|
||||
'v' 00-0F linux/sonypi.h conflict!
|
||||
'v' C0-CF drivers/media/video/ov511.h conflict!
|
||||
'v' C0-DF media/pwc-ioctl.h conflict!
|
||||
'v' C0-FF linux/meye.h conflict!
|
||||
'v' C0-CF drivers/media/video/zoran/zoran.h conflict!
|
||||
'v' D0-DF drivers/media/video/cpia2/cpia2dev.h conflict!
|
||||
'w' all CERN SCI driver
|
||||
'y' 00-1F packet based user level communications
|
||||
@ -278,7 +273,6 @@ Code Seq#(hex) Include File Comments
|
||||
<mailto:oe@port.de>
|
||||
'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict!
|
||||
0x80 00-1F linux/fb.h
|
||||
0x88 00-3F media/ovcamchip.h
|
||||
0x89 00-06 arch/x86/include/asm/sockios.h
|
||||
0x89 0B-DF linux/sockios.h
|
||||
0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range
|
||||
|
||||
@ -81,7 +81,7 @@ Field 9 -- # of I/Os currently in progress
|
||||
The only field that should go to zero. Incremented as requests are
|
||||
given to appropriate struct request_queue and decremented as they finish.
|
||||
Field 10 -- # of milliseconds spent doing I/Os
|
||||
This field is increases so long as field 9 is nonzero.
|
||||
This field increases so long as field 9 is nonzero.
|
||||
Field 11 -- weighted # of milliseconds spent doing I/Os
|
||||
This field is incremented at each I/O start, I/O completion, I/O
|
||||
merge, or read of these stats by the number of I/Os in progress
|
||||
|
||||
@ -73,6 +73,14 @@ Specify the output directory when building the kernel.
|
||||
The output directory can also be specified using "O=...".
|
||||
Setting "O=..." takes precedence over KBUILD_OUTPUT.
|
||||
|
||||
KBUILD_DEBARCH
|
||||
--------------------------------------------------
|
||||
For the deb-pkg target, allows overriding the normal heuristics deployed by
|
||||
deb-pkg. Normally deb-pkg attempts to guess the right architecture based on
|
||||
the UTS_MACHINE variable, and on some architectures also the kernel config.
|
||||
The value of KBUILD_DEBARCH is assumed (not checked) to be a valid Debian
|
||||
architecture.
|
||||
|
||||
ARCH
|
||||
--------------------------------------------------
|
||||
Set ARCH to the architecture to be built.
|
||||
|
||||
@ -112,7 +112,6 @@ applicable everywhere (see syntax).
|
||||
(no prompts anywhere) and for symbols with no dependencies.
|
||||
That will limit the usefulness but on the other hand avoid
|
||||
the illegal configurations all over.
|
||||
kconfig should one day warn about such things.
|
||||
|
||||
- numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
|
||||
This allows to limit the range of possible input values for int
|
||||
@ -268,7 +267,7 @@ separate list of options.
|
||||
|
||||
choices:
|
||||
|
||||
"choice"
|
||||
"choice" [symbol]
|
||||
<choice options>
|
||||
<choice block>
|
||||
"endchoice"
|
||||
@ -282,6 +281,10 @@ single driver can be compiled/loaded into the kernel, but all drivers
|
||||
can be compiled as modules.
|
||||
A choice accepts another option "optional", which allows to set the
|
||||
choice to 'n' and no entry needs to be selected.
|
||||
If no [symbol] is associated with a choice, then you can not have multiple
|
||||
definitions of that choice. If a [symbol] is associated to the choice,
|
||||
then you may define the same choice (ie. with the same entries) in another
|
||||
place.
|
||||
|
||||
comment:
|
||||
|
||||
|
||||
@ -1136,6 +1136,21 @@ When kbuild executes, the following steps are followed (roughly):
|
||||
resulting in the target file being recompiled for no
|
||||
obvious reason.
|
||||
|
||||
dtc
|
||||
Create flattend device tree blob object suitable for linking
|
||||
into vmlinux. Device tree blobs linked into vmlinux are placed
|
||||
in an init section in the image. Platform code *must* copy the
|
||||
blob to non-init memory prior to calling unflatten_device_tree().
|
||||
|
||||
Example:
|
||||
#arch/x86/platform/ce4100/Makefile
|
||||
clean-files := *dtb.S
|
||||
|
||||
DTC_FLAGS := -p 1024
|
||||
obj-y += foo.dtb.o
|
||||
|
||||
$(obj)/%.dtb: $(src)/%.dts
|
||||
$(call cmd,dtc)
|
||||
|
||||
--- 6.7 Custom kbuild commands
|
||||
|
||||
|
||||
@ -65,18 +65,21 @@ Install kexec-tools
|
||||
|
||||
2) Download the kexec-tools user-space package from the following URL:
|
||||
|
||||
http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools.tar.gz
|
||||
http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools.tar.gz
|
||||
|
||||
This is a symlink to the latest version.
|
||||
|
||||
The latest kexec-tools git tree is available at:
|
||||
|
||||
git://git.kernel.org/pub/scm/linux/kernel/git/horms/kexec-tools.git
|
||||
or
|
||||
http://www.kernel.org/git/?p=linux/kernel/git/horms/kexec-tools.git
|
||||
git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
|
||||
and
|
||||
http://www.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
|
||||
|
||||
There is also a gitweb interface available at
|
||||
http://www.kernel.org/git/?p=utils/kernel/kexec/kexec-tools.git
|
||||
|
||||
More information about kexec-tools can be found at
|
||||
http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/README.html
|
||||
http://www.kernel.org/pub/linux/utils/kernel/kexec/README.html
|
||||
|
||||
3) Unpack the tarball with the tar command, as follows:
|
||||
|
||||
@ -439,6 +442,6 @@ To Do
|
||||
Contact
|
||||
=======
|
||||
|
||||
Vivek Goyal (vgoyal@in.ibm.com)
|
||||
Vivek Goyal (vgoyal@redhat.com)
|
||||
Maneesh Soni (maneesh@in.ibm.com)
|
||||
|
||||
|
||||
@ -537,7 +537,7 @@
|
||||
Notes: Further information in
|
||||
http://www.oreilly.com/catalog/linuxdrive2/
|
||||
|
||||
* Title: "Linux Device Drivers, 3nd Edition"
|
||||
* Title: "Linux Device Drivers, 3rd Edition"
|
||||
Authors: Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman
|
||||
Publisher: O'Reilly & Associates.
|
||||
Date: 2005.
|
||||
@ -592,14 +592,6 @@
|
||||
Pages: 600.
|
||||
ISBN: 0-13-101908-2
|
||||
|
||||
* Title: "The Design and Implementation of the 4.4 BSD UNIX
|
||||
Operating System"
|
||||
Author: Marshall Kirk McKusick, Keith Bostic, Michael J. Karels,
|
||||
John S. Quarterman.
|
||||
Publisher: Addison-Wesley.
|
||||
Date: 1996.
|
||||
ISBN: 0-201-54979-4
|
||||
|
||||
* Title: "Programming for the real world - POSIX.4"
|
||||
Author: Bill O. Gallmeister.
|
||||
Publisher: O'Reilly & Associates, Inc..
|
||||
@ -610,28 +602,13 @@
|
||||
POSIX. Good reference.
|
||||
|
||||
* Title: "UNIX Systems for Modern Architectures: Symmetric
|
||||
Multiprocesssing and Caching for Kernel Programmers"
|
||||
Multiprocessing and Caching for Kernel Programmers"
|
||||
Author: Curt Schimmel.
|
||||
Publisher: Addison Wesley.
|
||||
Date: June, 1994.
|
||||
Pages: 432.
|
||||
ISBN: 0-201-63338-8
|
||||
|
||||
* Title: "The Design and Implementation of the 4.3 BSD UNIX
|
||||
Operating System"
|
||||
Author: Samuel J. Leffler, Marshall Kirk McKusick, Michael J.
|
||||
Karels, John S. Quarterman.
|
||||
Publisher: Addison-Wesley.
|
||||
Date: 1989 (reprinted with corrections on October, 1990).
|
||||
ISBN: 0-201-06196-1
|
||||
|
||||
* Title: "The Design of the UNIX Operating System"
|
||||
Author: Maurice J. Bach.
|
||||
Publisher: Prentice Hall.
|
||||
Date: 1986.
|
||||
Pages: 471.
|
||||
ISBN: 0-13-201757-1
|
||||
|
||||
MISCELLANEOUS:
|
||||
|
||||
* Name: linux/Documentation
|
||||
|
||||
@ -43,11 +43,11 @@ parameter is applicable:
|
||||
AVR32 AVR32 architecture is enabled.
|
||||
AX25 Appropriate AX.25 support is enabled.
|
||||
BLACKFIN Blackfin architecture is enabled.
|
||||
DRM Direct Rendering Management support is enabled.
|
||||
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
|
||||
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
|
||||
EFI EFI Partitioning (GPT) is enabled
|
||||
EIDE EIDE/ATAPI support is enabled.
|
||||
DRM Direct Rendering Management support is enabled.
|
||||
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
|
||||
FB The frame buffer device is enabled.
|
||||
GCOV GCOV profiling is enabled.
|
||||
HW Appropriate hardware is enabled.
|
||||
@ -199,11 +199,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
unusable. The "log_buf_len" parameter may be useful
|
||||
if you need to capture more output.
|
||||
|
||||
acpi_display_output= [HW,ACPI]
|
||||
acpi_display_output=vendor
|
||||
acpi_display_output=video
|
||||
See above.
|
||||
|
||||
acpi_irq_balance [HW,ACPI]
|
||||
ACPI will balance active IRQs
|
||||
default in APIC mode
|
||||
@ -403,6 +398,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
bttv.pll= See Documentation/video4linux/bttv/Insmod-options
|
||||
bttv.tuner= and Documentation/video4linux/bttv/CARDLIST
|
||||
|
||||
bulk_remove=off [PPC] This parameter disables the use of the pSeries
|
||||
firmware feature for flushing multiple hpte entries
|
||||
at a time.
|
||||
|
||||
c101= [NET] Moxa C101 synchronous serial card
|
||||
|
||||
cachesize= [BUGS=X86-32] Override level 2 CPU cache size detection.
|
||||
@ -655,11 +654,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
|
||||
dscc4.setup= [NET]
|
||||
|
||||
dynamic_printk Enables pr_debug()/dev_dbg() calls if
|
||||
CONFIG_DYNAMIC_PRINTK_DEBUG has been enabled.
|
||||
These can also be switched on/off via
|
||||
<debugfs>/dynamic_printk/modules
|
||||
|
||||
earlycon= [KNL] Output early console device and options.
|
||||
uart[8250],io,<addr>[,options]
|
||||
uart[8250],mmio,<addr>[,options]
|
||||
@ -706,7 +700,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
|
||||
|
||||
elevator= [IOSCHED]
|
||||
Format: {"anticipatory" | "cfq" | "deadline" | "noop"}
|
||||
Format: {"cfq" | "deadline" | "noop"}
|
||||
See Documentation/block/as-iosched.txt and
|
||||
Documentation/block/deadline-iosched.txt for details.
|
||||
|
||||
@ -1491,6 +1485,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
mtdparts= [MTD]
|
||||
See drivers/mtd/cmdlinepart.c.
|
||||
|
||||
multitce=off [PPC] This parameter disables the use of the pSeries
|
||||
firmware feature for updating multiple TCE entries
|
||||
at a time.
|
||||
|
||||
onenand.bdry= [HW,MTD] Flex-OneNAND Boundary Configuration
|
||||
|
||||
Format: [die0_boundary][,die0_lock][,die1_boundary][,die1_lock]
|
||||
@ -1580,20 +1578,12 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
|
||||
nmi_watchdog= [KNL,BUGS=X86] Debugging features for SMP kernels
|
||||
Format: [panic,][num]
|
||||
Valid num: 0,1,2
|
||||
Valid num: 0
|
||||
0 - turn nmi_watchdog off
|
||||
1 - use the IO-APIC timer for the NMI watchdog
|
||||
2 - use the local APIC for the NMI watchdog using
|
||||
a performance counter. Note: This will use one
|
||||
performance counter and the local APIC's performance
|
||||
vector.
|
||||
When panic is specified, panic when an NMI watchdog
|
||||
timeout occurs.
|
||||
This is useful when you use a panic=... timeout and
|
||||
need the box quickly up again.
|
||||
Instead of 1 and 2 it is possible to use the following
|
||||
symbolic names: lapic and ioapic
|
||||
Example: nmi_watchdog=2 or nmi_watchdog=panic,lapic
|
||||
|
||||
netpoll.carrier_timeout=
|
||||
[NET] Specifies amount of time (in seconds) that
|
||||
@ -1623,6 +1613,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
noapic [SMP,APIC] Tells the kernel to not make use of any
|
||||
IOAPICs that may be present in the system.
|
||||
|
||||
noautogroup Disable scheduler automatic task group creation.
|
||||
|
||||
nobats [PPC] Do not use BATs for mapping kernel lowmem
|
||||
on "Classic" PPC cores.
|
||||
|
||||
@ -1708,6 +1700,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
|
||||
no-kvmclock [X86,KVM] Disable paravirtualized KVM clock driver
|
||||
|
||||
no-kvmapf [X86,KVM] Disable paravirtualized asynchronous page
|
||||
fault handling.
|
||||
|
||||
nolapic [X86-32,APIC] Do not enable or use the local APIC.
|
||||
|
||||
nolapic_timer [X86-32,APIC] Do not use the local APIC timer.
|
||||
@ -1760,7 +1755,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
|
||||
nousb [USB] Disable the USB subsystem
|
||||
|
||||
nowatchdog [KNL] Disable the lockup detector.
|
||||
nowatchdog [KNL] Disable the lockup detector (NMI watchdog).
|
||||
|
||||
nowb [ARM]
|
||||
|
||||
@ -2176,11 +2171,6 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
reset_devices [KNL] Force drivers to reset the underlying device
|
||||
during initialization.
|
||||
|
||||
resource_alloc_from_bottom
|
||||
Allocate new resources from the beginning of available
|
||||
space, not the end. If you need to use this, please
|
||||
report a bug.
|
||||
|
||||
resume= [SWSUSP]
|
||||
Specify the partition device for software suspend
|
||||
|
||||
@ -2386,6 +2376,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
improve throughput, but will also increase the
|
||||
amount of memory reserved for use by the client.
|
||||
|
||||
swapaccount[=0|1]
|
||||
[KNL] Enable accounting of swap in memory resource
|
||||
controller if no parameter or 1 is given or disable
|
||||
it if 0 is given (See Documentation/cgroups/memory.txt)
|
||||
|
||||
swiotlb= [IA-64] Number of I/O TLB slabs
|
||||
|
||||
switches= [HW,M68k]
|
||||
@ -2468,12 +2463,13 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||
to facilitate early boot debugging.
|
||||
See also Documentation/trace/events.txt
|
||||
|
||||
tsc= Disable clocksource-must-verify flag for TSC.
|
||||
tsc= Disable clocksource stability checks for TSC.
|
||||
Format: <string>
|
||||
[x86] reliable: mark tsc clocksource as reliable, this
|
||||
disables clocksource verification at runtime.
|
||||
Used to enable high-resolution timer mode on older
|
||||
hardware, and in virtualized environment.
|
||||
disables clocksource verification at runtime, as well
|
||||
as the stability checks done at bootup. Used to enable
|
||||
high-resolution timer mode on older hardware, and in
|
||||
virtualized environment.
|
||||
[x86] noirqtime: Do not use TSC to do irq accounting.
|
||||
Used to run time disable IRQ_TIME_ACCOUNTING on any
|
||||
platforms where RDTSC is slow and this accounting
|
||||
|
||||
145
Documentation/keys-trusted-encrypted.txt
Normal file
145
Documentation/keys-trusted-encrypted.txt
Normal file
@ -0,0 +1,145 @@
|
||||
Trusted and Encrypted Keys
|
||||
|
||||
Trusted and Encrypted Keys are two new key types added to the existing kernel
|
||||
key ring service. Both of these new types are variable length symmetic keys,
|
||||
and in both cases all keys are created in the kernel, and user space sees,
|
||||
stores, and loads only encrypted blobs. Trusted Keys require the availability
|
||||
of a Trusted Platform Module (TPM) chip for greater security, while Encrypted
|
||||
Keys can be used on any system. All user level blobs, are displayed and loaded
|
||||
in hex ascii for convenience, and are integrity verified.
|
||||
|
||||
Trusted Keys use a TPM both to generate and to seal the keys. Keys are sealed
|
||||
under a 2048 bit RSA key in the TPM, and optionally sealed to specified PCR
|
||||
(integrity measurement) values, and only unsealed by the TPM, if PCRs and blob
|
||||
integrity verifications match. A loaded Trusted Key can be updated with new
|
||||
(future) PCR values, so keys are easily migrated to new pcr values, such as
|
||||
when the kernel and initramfs are updated. The same key can have many saved
|
||||
blobs under different PCR values, so multiple boots are easily supported.
|
||||
|
||||
By default, trusted keys are sealed under the SRK, which has the default
|
||||
authorization value (20 zeros). This can be set at takeownership time with the
|
||||
trouser's utility: "tpm_takeownership -u -z".
|
||||
|
||||
Usage:
|
||||
keyctl add trusted name "new keylen [options]" ring
|
||||
keyctl add trusted name "load hex_blob [pcrlock=pcrnum]" ring
|
||||
keyctl update key "update [options]"
|
||||
keyctl print keyid
|
||||
|
||||
options:
|
||||
keyhandle= ascii hex value of sealing key default 0x40000000 (SRK)
|
||||
keyauth= ascii hex auth for sealing key default 0x00...i
|
||||
(40 ascii zeros)
|
||||
blobauth= ascii hex auth for sealed data default 0x00...
|
||||
(40 ascii zeros)
|
||||
blobauth= ascii hex auth for sealed data default 0x00...
|
||||
(40 ascii zeros)
|
||||
pcrinfo= ascii hex of PCR_INFO or PCR_INFO_LONG (no default)
|
||||
pcrlock= pcr number to be extended to "lock" blob
|
||||
migratable= 0|1 indicating permission to reseal to new PCR values,
|
||||
default 1 (resealing allowed)
|
||||
|
||||
"keyctl print" returns an ascii hex copy of the sealed key, which is in standard
|
||||
TPM_STORED_DATA format. The key length for new keys are always in bytes.
|
||||
Trusted Keys can be 32 - 128 bytes (256 - 1024 bits), the upper limit is to fit
|
||||
within the 2048 bit SRK (RSA) keylength, with all necessary structure/padding.
|
||||
|
||||
Encrypted keys do not depend on a TPM, and are faster, as they use AES for
|
||||
encryption/decryption. New keys are created from kernel generated random
|
||||
numbers, and are encrypted/decrypted using a specified 'master' key. The
|
||||
'master' key can either be a trusted-key or user-key type. The main
|
||||
disadvantage of encrypted keys is that if they are not rooted in a trusted key,
|
||||
they are only as secure as the user key encrypting them. The master user key
|
||||
should therefore be loaded in as secure a way as possible, preferably early in
|
||||
boot.
|
||||
|
||||
Usage:
|
||||
keyctl add encrypted name "new key-type:master-key-name keylen" ring
|
||||
keyctl add encrypted name "load hex_blob" ring
|
||||
keyctl update keyid "update key-type:master-key-name"
|
||||
|
||||
where 'key-type' is either 'trusted' or 'user'.
|
||||
|
||||
Examples of trusted and encrypted key usage:
|
||||
|
||||
Create and save a trusted key named "kmk" of length 32 bytes:
|
||||
|
||||
$ keyctl add trusted kmk "new 32" @u
|
||||
440502848
|
||||
|
||||
$ keyctl show
|
||||
Session Keyring
|
||||
-3 --alswrv 500 500 keyring: _ses
|
||||
97833714 --alswrv 500 -1 \_ keyring: _uid.500
|
||||
440502848 --alswrv 500 500 \_ trusted: kmk
|
||||
|
||||
$ keyctl print 440502848
|
||||
0101000000000000000001005d01b7e3f4a6be5709930f3b70a743cbb42e0cc95e18e915
|
||||
3f60da455bbf1144ad12e4f92b452f966929f6105fd29ca28e4d4d5a031d068478bacb0b
|
||||
27351119f822911b0a11ba3d3498ba6a32e50dac7f32894dd890eb9ad578e4e292c83722
|
||||
a52e56a097e6a68b3f56f7a52ece0cdccba1eb62cad7d817f6dc58898b3ac15f36026fec
|
||||
d568bd4a706cb60bb37be6d8f1240661199d640b66fb0fe3b079f97f450b9ef9c22c6d5d
|
||||
dd379f0facd1cd020281dfa3c70ba21a3fa6fc2471dc6d13ecf8298b946f65345faa5ef0
|
||||
f1f8fff03ad0acb083725535636addb08d73dedb9832da198081e5deae84bfaf0409c22b
|
||||
e4a8aea2b607ec96931e6f4d4fe563ba
|
||||
|
||||
$ keyctl pipe 440502848 > kmk.blob
|
||||
|
||||
Load a trusted key from the saved blob:
|
||||
|
||||
$ keyctl add trusted kmk "load `cat kmk.blob`" @u
|
||||
268728824
|
||||
|
||||
$ keyctl print 268728824
|
||||
0101000000000000000001005d01b7e3f4a6be5709930f3b70a743cbb42e0cc95e18e915
|
||||
3f60da455bbf1144ad12e4f92b452f966929f6105fd29ca28e4d4d5a031d068478bacb0b
|
||||
27351119f822911b0a11ba3d3498ba6a32e50dac7f32894dd890eb9ad578e4e292c83722
|
||||
a52e56a097e6a68b3f56f7a52ece0cdccba1eb62cad7d817f6dc58898b3ac15f36026fec
|
||||
d568bd4a706cb60bb37be6d8f1240661199d640b66fb0fe3b079f97f450b9ef9c22c6d5d
|
||||
dd379f0facd1cd020281dfa3c70ba21a3fa6fc2471dc6d13ecf8298b946f65345faa5ef0
|
||||
f1f8fff03ad0acb083725535636addb08d73dedb9832da198081e5deae84bfaf0409c22b
|
||||
e4a8aea2b607ec96931e6f4d4fe563ba
|
||||
|
||||
Reseal a trusted key under new pcr values:
|
||||
|
||||
$ keyctl update 268728824 "update pcrinfo=`cat pcr.blob`"
|
||||
$ keyctl print 268728824
|
||||
010100000000002c0002800093c35a09b70fff26e7a98ae786c641e678ec6ffb6b46d805
|
||||
77c8a6377aed9d3219c6dfec4b23ffe3000001005d37d472ac8a44023fbb3d18583a4f73
|
||||
d3a076c0858f6f1dcaa39ea0f119911ff03f5406df4f7f27f41da8d7194f45c9f4e00f2e
|
||||
df449f266253aa3f52e55c53de147773e00f0f9aca86c64d94c95382265968c354c5eab4
|
||||
9638c5ae99c89de1e0997242edfb0b501744e11ff9762dfd951cffd93227cc513384e7e6
|
||||
e782c29435c7ec2edafaa2f4c1fe6e7a781b59549ff5296371b42133777dcc5b8b971610
|
||||
94bc67ede19e43ddb9dc2baacad374a36feaf0314d700af0a65c164b7082401740e489c9
|
||||
7ef6a24defe4846104209bf0c3eced7fa1a672ed5b125fc9d8cd88b476a658a4434644ef
|
||||
df8ae9a178e9f83ba9f08d10fa47e4226b98b0702f06b3b8
|
||||
|
||||
Create and save an encrypted key "evm" using the above trusted key "kmk":
|
||||
|
||||
$ keyctl add encrypted evm "new trusted:kmk 32" @u
|
||||
159771175
|
||||
|
||||
$ keyctl print 159771175
|
||||
trusted:kmk 32 2375725ad57798846a9bbd240de8906f006e66c03af53b1b382dbbc55
|
||||
be2a44616e4959430436dc4f2a7a9659aa60bb4652aeb2120f149ed197c564e024717c64
|
||||
5972dcb82ab2dde83376d82b2e3c09ffc
|
||||
|
||||
$ keyctl pipe 159771175 > evm.blob
|
||||
|
||||
Load an encrypted key "evm" from saved blob:
|
||||
|
||||
$ keyctl add encrypted evm "load `cat evm.blob`" @u
|
||||
831684262
|
||||
|
||||
$ keyctl print 831684262
|
||||
trusted:kmk 32 2375725ad57798846a9bbd240de8906f006e66c03af53b1b382dbbc55
|
||||
be2a44616e4959430436dc4f2a7a9659aa60bb4652aeb2120f149ed197c564e024717c64
|
||||
5972dcb82ab2dde83376d82b2e3c09ffc
|
||||
|
||||
|
||||
The initial consumer of trusted keys is EVM, which at boot time needs a high
|
||||
quality symmetric key for HMAC protection of file metadata. The use of a
|
||||
trusted key provides strong guarantees that the EVM key has not been
|
||||
compromised by a user level problem, and when sealed to specific boot PCR
|
||||
values, protects against boot and offline attacks. Other uses for trusted and
|
||||
encrypted keys, such as for disk and file encryption are anticipated.
|
||||
@ -391,8 +391,8 @@ bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에
|
||||
bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다)
|
||||
에 등록하면 된다.
|
||||
|
||||
http://lists.osdl.org/mailman/listinfo/bugme-new
|
||||
http://lists.osdl.org/mailman/listinfo/bugme-janitors
|
||||
https://lists.linux-foundation.org/mailman/listinfo/bugme-new
|
||||
https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
|
||||
|
||||
|
||||
|
||||
|
||||
@ -598,7 +598,7 @@ a 5-byte jump instruction. So there are several limitations.
|
||||
a) The instructions in DCR must be relocatable.
|
||||
b) The instructions in DCR must not include a call instruction.
|
||||
c) JTPR must not be targeted by any jump or call instruction.
|
||||
d) DCR must not straddle the border betweeen functions.
|
||||
d) DCR must not straddle the border between functions.
|
||||
|
||||
Anyway, these limitations are checked by the in-kernel instruction
|
||||
decoder, so you don't need to worry about that.
|
||||
|
||||
@ -874,7 +874,7 @@ Possible values are:
|
||||
- KVM_MP_STATE_HALTED: the vcpu has executed a HLT instruction and
|
||||
is waiting for an interrupt
|
||||
- KVM_MP_STATE_SIPI_RECEIVED: the vcpu has just received a SIPI (vector
|
||||
accesible via KVM_GET_VCPU_EVENTS)
|
||||
accessible via KVM_GET_VCPU_EVENTS)
|
||||
|
||||
This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel
|
||||
irqchip, the multiprocessing state must be maintained by userspace.
|
||||
@ -1085,6 +1085,184 @@ of 4 instructions that make up a hypercall.
|
||||
If any additional field gets added to this structure later on, a bit for that
|
||||
additional piece of information will be set in the flags bitmap.
|
||||
|
||||
4.47 KVM_ASSIGN_PCI_DEVICE
|
||||
|
||||
Capability: KVM_CAP_DEVICE_ASSIGNMENT
|
||||
Architectures: x86 ia64
|
||||
Type: vm ioctl
|
||||
Parameters: struct kvm_assigned_pci_dev (in)
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
Assigns a host PCI device to the VM.
|
||||
|
||||
struct kvm_assigned_pci_dev {
|
||||
__u32 assigned_dev_id;
|
||||
__u32 busnr;
|
||||
__u32 devfn;
|
||||
__u32 flags;
|
||||
__u32 segnr;
|
||||
union {
|
||||
__u32 reserved[11];
|
||||
};
|
||||
};
|
||||
|
||||
The PCI device is specified by the triple segnr, busnr, and devfn.
|
||||
Identification in succeeding service requests is done via assigned_dev_id. The
|
||||
following flags are specified:
|
||||
|
||||
/* Depends on KVM_CAP_IOMMU */
|
||||
#define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
|
||||
|
||||
4.48 KVM_DEASSIGN_PCI_DEVICE
|
||||
|
||||
Capability: KVM_CAP_DEVICE_DEASSIGNMENT
|
||||
Architectures: x86 ia64
|
||||
Type: vm ioctl
|
||||
Parameters: struct kvm_assigned_pci_dev (in)
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
Ends PCI device assignment, releasing all associated resources.
|
||||
|
||||
See KVM_CAP_DEVICE_ASSIGNMENT for the data structure. Only assigned_dev_id is
|
||||
used in kvm_assigned_pci_dev to identify the device.
|
||||
|
||||
4.49 KVM_ASSIGN_DEV_IRQ
|
||||
|
||||
Capability: KVM_CAP_ASSIGN_DEV_IRQ
|
||||
Architectures: x86 ia64
|
||||
Type: vm ioctl
|
||||
Parameters: struct kvm_assigned_irq (in)
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
Assigns an IRQ to a passed-through device.
|
||||
|
||||
struct kvm_assigned_irq {
|
||||
__u32 assigned_dev_id;
|
||||
__u32 host_irq;
|
||||
__u32 guest_irq;
|
||||
__u32 flags;
|
||||
union {
|
||||
struct {
|
||||
__u32 addr_lo;
|
||||
__u32 addr_hi;
|
||||
__u32 data;
|
||||
} guest_msi;
|
||||
__u32 reserved[12];
|
||||
};
|
||||
};
|
||||
|
||||
The following flags are defined:
|
||||
|
||||
#define KVM_DEV_IRQ_HOST_INTX (1 << 0)
|
||||
#define KVM_DEV_IRQ_HOST_MSI (1 << 1)
|
||||
#define KVM_DEV_IRQ_HOST_MSIX (1 << 2)
|
||||
|
||||
#define KVM_DEV_IRQ_GUEST_INTX (1 << 8)
|
||||
#define KVM_DEV_IRQ_GUEST_MSI (1 << 9)
|
||||
#define KVM_DEV_IRQ_GUEST_MSIX (1 << 10)
|
||||
|
||||
It is not valid to specify multiple types per host or guest IRQ. However, the
|
||||
IRQ type of host and guest can differ or can even be null.
|
||||
|
||||
4.50 KVM_DEASSIGN_DEV_IRQ
|
||||
|
||||
Capability: KVM_CAP_ASSIGN_DEV_IRQ
|
||||
Architectures: x86 ia64
|
||||
Type: vm ioctl
|
||||
Parameters: struct kvm_assigned_irq (in)
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
Ends an IRQ assignment to a passed-through device.
|
||||
|
||||
See KVM_ASSIGN_DEV_IRQ for the data structure. The target device is specified
|
||||
by assigned_dev_id, flags must correspond to the IRQ type specified on
|
||||
KVM_ASSIGN_DEV_IRQ. Partial deassignment of host or guest IRQ is allowed.
|
||||
|
||||
4.51 KVM_SET_GSI_ROUTING
|
||||
|
||||
Capability: KVM_CAP_IRQ_ROUTING
|
||||
Architectures: x86 ia64
|
||||
Type: vm ioctl
|
||||
Parameters: struct kvm_irq_routing (in)
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
Sets the GSI routing table entries, overwriting any previously set entries.
|
||||
|
||||
struct kvm_irq_routing {
|
||||
__u32 nr;
|
||||
__u32 flags;
|
||||
struct kvm_irq_routing_entry entries[0];
|
||||
};
|
||||
|
||||
No flags are specified so far, the corresponding field must be set to zero.
|
||||
|
||||
struct kvm_irq_routing_entry {
|
||||
__u32 gsi;
|
||||
__u32 type;
|
||||
__u32 flags;
|
||||
__u32 pad;
|
||||
union {
|
||||
struct kvm_irq_routing_irqchip irqchip;
|
||||
struct kvm_irq_routing_msi msi;
|
||||
__u32 pad[8];
|
||||
} u;
|
||||
};
|
||||
|
||||
/* gsi routing entry types */
|
||||
#define KVM_IRQ_ROUTING_IRQCHIP 1
|
||||
#define KVM_IRQ_ROUTING_MSI 2
|
||||
|
||||
No flags are specified so far, the corresponding field must be set to zero.
|
||||
|
||||
struct kvm_irq_routing_irqchip {
|
||||
__u32 irqchip;
|
||||
__u32 pin;
|
||||
};
|
||||
|
||||
struct kvm_irq_routing_msi {
|
||||
__u32 address_lo;
|
||||
__u32 address_hi;
|
||||
__u32 data;
|
||||
__u32 pad;
|
||||
};
|
||||
|
||||
4.52 KVM_ASSIGN_SET_MSIX_NR
|
||||
|
||||
Capability: KVM_CAP_DEVICE_MSIX
|
||||
Architectures: x86 ia64
|
||||
Type: vm ioctl
|
||||
Parameters: struct kvm_assigned_msix_nr (in)
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
Set the number of MSI-X interrupts for an assigned device. This service can
|
||||
only be called once in the lifetime of an assigned device.
|
||||
|
||||
struct kvm_assigned_msix_nr {
|
||||
__u32 assigned_dev_id;
|
||||
__u16 entry_nr;
|
||||
__u16 padding;
|
||||
};
|
||||
|
||||
#define KVM_MAX_MSIX_PER_DEV 256
|
||||
|
||||
4.53 KVM_ASSIGN_SET_MSIX_ENTRY
|
||||
|
||||
Capability: KVM_CAP_DEVICE_MSIX
|
||||
Architectures: x86 ia64
|
||||
Type: vm ioctl
|
||||
Parameters: struct kvm_assigned_msix_entry (in)
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
Specifies the routing of an MSI-X assigned device interrupt to a GSI. Setting
|
||||
the GSI vector to zero means disabling the interrupt.
|
||||
|
||||
struct kvm_assigned_msix_entry {
|
||||
__u32 assigned_dev_id;
|
||||
__u32 gsi;
|
||||
__u16 entry; /* The index of entry in the MSI-X table */
|
||||
__u16 padding[3];
|
||||
};
|
||||
|
||||
5. The kvm_run structure
|
||||
|
||||
Application code obtains a pointer to the kvm_run structure by
|
||||
|
||||
@ -36,6 +36,9 @@ KVM_FEATURE_MMU_OP || 2 || deprecated.
|
||||
KVM_FEATURE_CLOCKSOURCE2 || 3 || kvmclock available at msrs
|
||||
|| || 0x4b564d00 and 0x4b564d01
|
||||
------------------------------------------------------------------------------
|
||||
KVM_FEATURE_ASYNC_PF || 4 || async pf can be enabled by
|
||||
|| || writing to msr 0x4b564d02
|
||||
------------------------------------------------------------------------------
|
||||
KVM_FEATURE_CLOCKSOURCE_STABLE_BIT || 24 || host will warn if no guest-side
|
||||
|| || per-cpu warps are expected in
|
||||
|| || kvmclock.
|
||||
|
||||
@ -3,7 +3,6 @@ Glauber Costa <glommer@redhat.com>, Red Hat Inc, 2010
|
||||
=====================================================
|
||||
|
||||
KVM makes use of some custom MSRs to service some requests.
|
||||
At present, this facility is only used by kvmclock.
|
||||
|
||||
Custom MSRs have a range reserved for them, that goes from
|
||||
0x4b564d00 to 0x4b564dff. There are MSRs outside this area,
|
||||
@ -151,3 +150,38 @@ MSR_KVM_SYSTEM_TIME: 0x12
|
||||
return PRESENT;
|
||||
} else
|
||||
return NON_PRESENT;
|
||||
|
||||
MSR_KVM_ASYNC_PF_EN: 0x4b564d02
|
||||
data: Bits 63-6 hold 64-byte aligned physical address of a
|
||||
64 byte memory area which must be in guest RAM and must be
|
||||
zeroed. Bits 5-2 are reserved and should be zero. Bit 0 is 1
|
||||
when asynchronous page faults are enabled on the vcpu 0 when
|
||||
disabled. Bit 2 is 1 if asynchronous page faults can be injected
|
||||
when vcpu is in cpl == 0.
|
||||
|
||||
First 4 byte of 64 byte memory location will be written to by
|
||||
the hypervisor at the time of asynchronous page fault (APF)
|
||||
injection to indicate type of asynchronous page fault. Value
|
||||
of 1 means that the page referred to by the page fault is not
|
||||
present. Value 2 means that the page is now available. Disabling
|
||||
interrupt inhibits APFs. Guest must not enable interrupt
|
||||
before the reason is read, or it may be overwritten by another
|
||||
APF. Since APF uses the same exception vector as regular page
|
||||
fault guest must reset the reason to 0 before it does
|
||||
something that can generate normal page fault. If during page
|
||||
fault APF reason is 0 it means that this is regular page
|
||||
fault.
|
||||
|
||||
During delivery of type 1 APF cr2 contains a token that will
|
||||
be used to notify a guest when missing page becomes
|
||||
available. When page becomes available type 2 APF is sent with
|
||||
cr2 set to the token associated with the page. There is special
|
||||
kind of token 0xffffffff which tells vcpu that it should wake
|
||||
up all processes waiting for APFs and no individual type 2 APFs
|
||||
will be sent.
|
||||
|
||||
If APF is disabled while there are outstanding APFs, they will
|
||||
not be delivered.
|
||||
|
||||
Currently type 2 APF will be always delivered on the same vcpu as
|
||||
type 1 was, but guest should not rely on that.
|
||||
|
||||
@ -60,15 +60,18 @@ Hardware accelerated blink of LEDs
|
||||
|
||||
Some LEDs can be programmed to blink without any CPU interaction. To
|
||||
support this feature, a LED driver can optionally implement the
|
||||
blink_set() function (see <linux/leds.h>). If implemented, triggers can
|
||||
attempt to use it before falling back to software timers. The blink_set()
|
||||
function should return 0 if the blink setting is supported, or -EINVAL
|
||||
otherwise, which means that LED blinking will be handled by software.
|
||||
blink_set() function (see <linux/leds.h>). To set an LED to blinking,
|
||||
however, it is better to use use the API function led_blink_set(),
|
||||
as it will check and implement software fallback if necessary.
|
||||
|
||||
The blink_set() function should choose a user friendly blinking
|
||||
value if it is called with *delay_on==0 && *delay_off==0 parameters. In
|
||||
this case the driver should give back the chosen value through delay_on
|
||||
and delay_off parameters to the leds subsystem.
|
||||
To turn off blinking again, use the API function led_brightness_set()
|
||||
as that will not just set the LED brightness but also stop any software
|
||||
timers that may have been required for blinking.
|
||||
|
||||
The blink_set() function should choose a user friendly blinking value
|
||||
if it is called with *delay_on==0 && *delay_off==0 parameters. In this
|
||||
case the driver should give back the chosen value through delay_on and
|
||||
delay_off parameters to the leds subsystem.
|
||||
|
||||
Setting the brightness to zero with brightness_set() callback function
|
||||
should completely turn off the LED and cancel the previously programmed
|
||||
|
||||
88
Documentation/leds/leds-lp5521.txt
Normal file
88
Documentation/leds/leds-lp5521.txt
Normal file
@ -0,0 +1,88 @@
|
||||
Kernel driver for lp5521
|
||||
========================
|
||||
|
||||
* National Semiconductor LP5521 led driver chip
|
||||
* Datasheet: http://www.national.com/pf/LP/LP5521.html
|
||||
|
||||
Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo
|
||||
Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
LP5521 can drive up to 3 channels. Leds can be controlled directly via
|
||||
the led class control interface. Channels have generic names:
|
||||
lp5521:channelx, where x is 0 .. 2
|
||||
|
||||
All three channels can be also controlled using the engine micro programs.
|
||||
More details of the instructions can be found from the public data sheet.
|
||||
|
||||
Control interface for the engines:
|
||||
x is 1 .. 3
|
||||
enginex_mode : disabled, load, run
|
||||
enginex_load : store program (visible only in engine load mode)
|
||||
|
||||
Example (start to blink the channel 2 led):
|
||||
cd /sys/class/leds/lp5521:channel2/device
|
||||
echo "load" > engine3_mode
|
||||
echo "037f4d0003ff6000" > engine3_load
|
||||
echo "run" > engine3_mode
|
||||
|
||||
stop the engine:
|
||||
echo "disabled" > engine3_mode
|
||||
|
||||
sysfs contains a selftest entry.
|
||||
The test communicates with the chip and checks that
|
||||
the clock mode is automatically set to the requested one.
|
||||
|
||||
Each channel has its own led current settings.
|
||||
/sys/class/leds/lp5521:channel0/led_current - RW
|
||||
/sys/class/leds/lp5521:channel0/max_current - RO
|
||||
Format: 10x mA i.e 10 means 1.0 mA
|
||||
|
||||
example platform data:
|
||||
|
||||
Note: chan_nr can have values between 0 and 2.
|
||||
|
||||
static struct lp5521_led_config lp5521_led_config[] = {
|
||||
{
|
||||
.chan_nr = 0,
|
||||
.led_current = 50,
|
||||
.max_current = 130,
|
||||
}, {
|
||||
.chan_nr = 1,
|
||||
.led_current = 0,
|
||||
.max_current = 130,
|
||||
}, {
|
||||
.chan_nr = 2,
|
||||
.led_current = 0,
|
||||
.max_current = 130,
|
||||
}
|
||||
};
|
||||
|
||||
static int lp5521_setup(void)
|
||||
{
|
||||
/* setup HW resources */
|
||||
}
|
||||
|
||||
static void lp5521_release(void)
|
||||
{
|
||||
/* Release HW resources */
|
||||
}
|
||||
|
||||
static void lp5521_enable(bool state)
|
||||
{
|
||||
/* Control of chip enable signal */
|
||||
}
|
||||
|
||||
static struct lp5521_platform_data lp5521_platform_data = {
|
||||
.led_config = lp5521_led_config,
|
||||
.num_channels = ARRAY_SIZE(lp5521_led_config),
|
||||
.clock_mode = LP5521_CLOCK_EXT,
|
||||
.setup_resources = lp5521_setup,
|
||||
.release_resources = lp5521_release,
|
||||
.enable = lp5521_enable,
|
||||
};
|
||||
|
||||
If the current is set to 0 in the platform data, that channel is
|
||||
disabled and it is not visible in the sysfs.
|
||||
83
Documentation/leds/leds-lp5523.txt
Normal file
83
Documentation/leds/leds-lp5523.txt
Normal file
@ -0,0 +1,83 @@
|
||||
Kernel driver for lp5523
|
||||
========================
|
||||
|
||||
* National Semiconductor LP5523 led driver chip
|
||||
* Datasheet: http://www.national.com/pf/LP/LP5523.html
|
||||
|
||||
Authors: Mathias Nyman, Yuri Zaporozhets, Samu Onkalo
|
||||
Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
|
||||
|
||||
Description
|
||||
-----------
|
||||
LP5523 can drive up to 9 channels. Leds can be controlled directly via
|
||||
the led class control interface. Channels have generic names:
|
||||
lp5523:channelx where x is 0...8
|
||||
|
||||
The chip provides 3 engines. Each engine can control channels without
|
||||
interaction from the main CPU. Details of the micro engine code can be found
|
||||
from the public data sheet. Leds can be muxed to different channels.
|
||||
|
||||
Control interface for the engines:
|
||||
x is 1 .. 3
|
||||
enginex_mode : disabled, load, run
|
||||
enginex_load : microcode load (visible only in load mode)
|
||||
enginex_leds : led mux control (visible only in load mode)
|
||||
|
||||
cd /sys/class/leds/lp5523:channel2/device
|
||||
echo "load" > engine3_mode
|
||||
echo "9d80400004ff05ff437f0000" > engine3_load
|
||||
echo "111111111" > engine3_leds
|
||||
echo "run" > engine3_mode
|
||||
|
||||
sysfs contains a selftest entry. It measures each channel
|
||||
voltage level and checks if it looks reasonable. If the level is too high,
|
||||
the led is missing; if the level is too low, there is a short circuit.
|
||||
|
||||
Selftest uses always the current from the platform data.
|
||||
|
||||
Each channel contains led current settings.
|
||||
/sys/class/leds/lp5523:channel2/led_current - RW
|
||||
/sys/class/leds/lp5523:channel2/max_current - RO
|
||||
Format: 10x mA i.e 10 means 1.0 mA
|
||||
|
||||
Example platform data:
|
||||
|
||||
Note - chan_nr can have values between 0 and 8.
|
||||
|
||||
static struct lp5523_led_config lp5523_led_config[] = {
|
||||
{
|
||||
.chan_nr = 0,
|
||||
.led_current = 50,
|
||||
.max_current = 130,
|
||||
},
|
||||
...
|
||||
}, {
|
||||
.chan_nr = 8,
|
||||
.led_current = 50,
|
||||
.max_current = 130,
|
||||
}
|
||||
};
|
||||
|
||||
static int lp5523_setup(void)
|
||||
{
|
||||
/* Setup HW resources */
|
||||
}
|
||||
|
||||
static void lp5523_release(void)
|
||||
{
|
||||
/* Release HW resources */
|
||||
}
|
||||
|
||||
static void lp5523_enable(bool state)
|
||||
{
|
||||
/* Control chip enable signal */
|
||||
}
|
||||
|
||||
static struct lp5523_platform_data lp5523_platform_data = {
|
||||
.led_config = lp5523_led_config,
|
||||
.num_channels = ARRAY_SIZE(lp5523_led_config),
|
||||
.clock_mode = LP5523_CLOCK_EXT,
|
||||
.setup_resources = lp5523_setup,
|
||||
.release_resources = lp5523_release,
|
||||
.enable = lp5523_enable,
|
||||
};
|
||||
@ -39,6 +39,9 @@
|
||||
#include <limits.h>
|
||||
#include <stddef.h>
|
||||
#include <signal.h>
|
||||
#include <pwd.h>
|
||||
#include <grp.h>
|
||||
|
||||
#include <linux/virtio_config.h>
|
||||
#include <linux/virtio_net.h>
|
||||
#include <linux/virtio_blk.h>
|
||||
@ -298,20 +301,27 @@ static void *map_zeroed_pages(unsigned int num)
|
||||
|
||||
/*
|
||||
* We use a private mapping (ie. if we write to the page, it will be
|
||||
* copied).
|
||||
* copied). We allocate an extra two pages PROT_NONE to act as guard
|
||||
* pages against read/write attempts that exceed allocated space.
|
||||
*/
|
||||
addr = mmap(NULL, getpagesize() * num,
|
||||
PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE, fd, 0);
|
||||
addr = mmap(NULL, getpagesize() * (num+2),
|
||||
PROT_NONE, MAP_PRIVATE, fd, 0);
|
||||
|
||||
if (addr == MAP_FAILED)
|
||||
err(1, "Mmapping %u pages of /dev/zero", num);
|
||||
|
||||
if (mprotect(addr + getpagesize(), getpagesize() * num,
|
||||
PROT_READ|PROT_WRITE) == -1)
|
||||
err(1, "mprotect rw %u pages failed", num);
|
||||
|
||||
/*
|
||||
* One neat mmap feature is that you can close the fd, and it
|
||||
* stays mapped.
|
||||
*/
|
||||
close(fd);
|
||||
|
||||
return addr;
|
||||
/* Return address after PROT_NONE page */
|
||||
return addr + getpagesize();
|
||||
}
|
||||
|
||||
/* Get some more pages for a device. */
|
||||
@ -343,7 +353,7 @@ static void map_at(int fd, void *addr, unsigned long offset, unsigned long len)
|
||||
* done to it. This allows us to share untouched memory between
|
||||
* Guests.
|
||||
*/
|
||||
if (mmap(addr, len, PROT_READ|PROT_WRITE|PROT_EXEC,
|
||||
if (mmap(addr, len, PROT_READ|PROT_WRITE,
|
||||
MAP_FIXED|MAP_PRIVATE, fd, offset) != MAP_FAILED)
|
||||
return;
|
||||
|
||||
@ -573,10 +583,10 @@ static void *_check_pointer(unsigned long addr, unsigned int size,
|
||||
unsigned int line)
|
||||
{
|
||||
/*
|
||||
* We have to separately check addr and addr+size, because size could
|
||||
* be huge and addr + size might wrap around.
|
||||
* Check if the requested address and size exceeds the allocated memory,
|
||||
* or addr + size wraps around.
|
||||
*/
|
||||
if (addr >= guest_limit || addr + size >= guest_limit)
|
||||
if ((addr + size) > guest_limit || (addr + size) < addr)
|
||||
errx(1, "%s:%i: Invalid address %#lx", __FILE__, line, addr);
|
||||
/*
|
||||
* We return a pointer for the caller's convenience, now we know it's
|
||||
@ -1872,6 +1882,8 @@ static struct option opts[] = {
|
||||
{ "block", 1, NULL, 'b' },
|
||||
{ "rng", 0, NULL, 'r' },
|
||||
{ "initrd", 1, NULL, 'i' },
|
||||
{ "username", 1, NULL, 'u' },
|
||||
{ "chroot", 1, NULL, 'c' },
|
||||
{ NULL },
|
||||
};
|
||||
static void usage(void)
|
||||
@ -1894,6 +1906,12 @@ int main(int argc, char *argv[])
|
||||
/* If they specify an initrd file to load. */
|
||||
const char *initrd_name = NULL;
|
||||
|
||||
/* Password structure for initgroups/setres[gu]id */
|
||||
struct passwd *user_details = NULL;
|
||||
|
||||
/* Directory to chroot to */
|
||||
char *chroot_path = NULL;
|
||||
|
||||
/* Save the args: we "reboot" by execing ourselves again. */
|
||||
main_args = argv;
|
||||
|
||||
@ -1950,6 +1968,14 @@ int main(int argc, char *argv[])
|
||||
case 'i':
|
||||
initrd_name = optarg;
|
||||
break;
|
||||
case 'u':
|
||||
user_details = getpwnam(optarg);
|
||||
if (!user_details)
|
||||
err(1, "getpwnam failed, incorrect username?");
|
||||
break;
|
||||
case 'c':
|
||||
chroot_path = optarg;
|
||||
break;
|
||||
default:
|
||||
warnx("Unknown argument %s", argv[optind]);
|
||||
usage();
|
||||
@ -2021,6 +2047,37 @@ int main(int argc, char *argv[])
|
||||
/* If we exit via err(), this kills all the threads, restores tty. */
|
||||
atexit(cleanup_devices);
|
||||
|
||||
/* If requested, chroot to a directory */
|
||||
if (chroot_path) {
|
||||
if (chroot(chroot_path) != 0)
|
||||
err(1, "chroot(\"%s\") failed", chroot_path);
|
||||
|
||||
if (chdir("/") != 0)
|
||||
err(1, "chdir(\"/\") failed");
|
||||
|
||||
verbose("chroot done\n");
|
||||
}
|
||||
|
||||
/* If requested, drop privileges */
|
||||
if (user_details) {
|
||||
uid_t u;
|
||||
gid_t g;
|
||||
|
||||
u = user_details->pw_uid;
|
||||
g = user_details->pw_gid;
|
||||
|
||||
if (initgroups(user_details->pw_name, g) != 0)
|
||||
err(1, "initgroups failed");
|
||||
|
||||
if (setresgid(g, g, g) != 0)
|
||||
err(1, "setresgid failed");
|
||||
|
||||
if (setresuid(u, u, u) != 0)
|
||||
err(1, "setresuid failed");
|
||||
|
||||
verbose("Dropping privileges completed\n");
|
||||
}
|
||||
|
||||
/* Finally, run the Guest. This doesn't return. */
|
||||
run_guest();
|
||||
}
|
||||
|
||||
@ -111,8 +111,16 @@ Running Lguest:
|
||||
|
||||
Then use --tunnet=bridge:lg0 when launching the guest.
|
||||
|
||||
See http://linux-net.osdl.org/index.php/Bridge for general information
|
||||
on how to get bridging working.
|
||||
See:
|
||||
|
||||
http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge
|
||||
|
||||
for general information on how to get bridging to work.
|
||||
|
||||
- Random number generation. Using the --rng option will provide a
|
||||
/dev/hwrng in the guest that will read from the host's /dev/random.
|
||||
Use this option in conjunction with rng-tools (see ../hw_random.txt)
|
||||
to provide entropy to the guest kernel's /dev/random.
|
||||
|
||||
There is a helpful mailing list at http://ozlabs.org/mailman/listinfo/lguest
|
||||
|
||||
|
||||
@ -150,7 +150,7 @@ NBD_REPLY_MAGIC 0x96744668 nbd_reply include/linux/nbd.h
|
||||
STL_BOARDMAGIC 0xa2267f52 stlbrd include/linux/stallion.h
|
||||
ENI155_MAGIC 0xa54b872d midway_eprom drivers/atm/eni.h
|
||||
SCI_MAGIC 0xbabeface gs_port drivers/char/sh-sci.h
|
||||
CODA_MAGIC 0xC0DAC0DA coda_file_info include/linux/coda_fs_i.h
|
||||
CODA_MAGIC 0xC0DAC0DA coda_file_info fs/coda/coda_fs_i.h
|
||||
DPMEM_MAGIC 0xc0ffee11 gdt_pci_sram drivers/scsi/gdth.h
|
||||
STLI_PORTMAGIC 0xe671c7a1 stliport include/linux/istallion.h
|
||||
YAM_MAGIC 0xF10A7654 yam_port drivers/net/hamradio/yam.c
|
||||
|
||||
@ -39,8 +39,9 @@ INSTALL_HDR_PATH indicates where to install the headers. It defaults to
|
||||
The command "make headers_install_all" exports headers for all architectures
|
||||
simultaneously. (This is mostly of interest to distribution maintainers,
|
||||
who create an architecture-independent tarball from the resulting include
|
||||
directory.) Remember to provide the appropriate linux/asm directory via "mv"
|
||||
or "ln -s" before building a C library with headers exported this way.
|
||||
directory.) You also can use HDR_ARCH_LIST to specify list of architectures.
|
||||
Remember to provide the appropriate linux/asm directory via "mv" or "ln -s"
|
||||
before building a C library with headers exported this way.
|
||||
|
||||
The kernel header export infrastructure is maintained by David Woodhouse
|
||||
<dwmw2@infradead.org>.
|
||||
|
||||
327
Documentation/networking/LICENSE.qlcnic
Normal file
327
Documentation/networking/LICENSE.qlcnic
Normal file
@ -0,0 +1,327 @@
|
||||
Copyright (c) 2009-2010 QLogic Corporation
|
||||
QLogic Linux qlcnic NIC Driver
|
||||
|
||||
This program includes a device driver for Linux 2.6 that may be
|
||||
distributed with QLogic hardware specific firmware binary file.
|
||||
You may modify and redistribute the device driver code under the
|
||||
GNU General Public License (a copy of which is attached hereto as
|
||||
Exhibit A) published by the Free Software Foundation (version 2).
|
||||
|
||||
You may redistribute the hardware specific firmware binary file
|
||||
under the following terms:
|
||||
|
||||
1. Redistribution of source code (only if applicable),
|
||||
must retain the above copyright notice, this list of
|
||||
conditions and the following disclaimer.
|
||||
|
||||
2. Redistribution in binary form must reproduce the above
|
||||
copyright notice, this list of conditions and the
|
||||
following disclaimer in the documentation and/or other
|
||||
materials provided with the distribution.
|
||||
|
||||
3. The name of QLogic Corporation may not be used to
|
||||
endorse or promote products derived from this software
|
||||
without specific prior written permission
|
||||
|
||||
REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE,
|
||||
THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "AS IS'' AND ANY
|
||||
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
|
||||
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR
|
||||
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
|
||||
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
|
||||
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
|
||||
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
|
||||
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
|
||||
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
||||
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGE.
|
||||
|
||||
USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT
|
||||
CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR
|
||||
OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT,
|
||||
TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN
|
||||
ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN
|
||||
COMBINATION WITH THIS PROGRAM.
|
||||
|
||||
|
||||
EXHIBIT A
|
||||
|
||||
GNU GENERAL PUBLIC LICENSE
|
||||
Version 2, June 1991
|
||||
|
||||
Copyright (C) 1989, 1991 Free Software Foundation, Inc.
|
||||
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
|
||||
Preamble
|
||||
|
||||
The licenses for most software are designed to take away your
|
||||
freedom to share and change it. By contrast, the GNU General Public
|
||||
License is intended to guarantee your freedom to share and change free
|
||||
software--to make sure the software is free for all its users. This
|
||||
General Public License applies to most of the Free Software
|
||||
Foundation's software and to any other program whose authors commit to
|
||||
using it. (Some other Free Software Foundation software is covered by
|
||||
the GNU Lesser General Public License instead.) You can apply it to
|
||||
your programs, too.
|
||||
|
||||
When we speak of free software, we are referring to freedom, not
|
||||
price. Our General Public Licenses are designed to make sure that you
|
||||
have the freedom to distribute copies of free software (and charge for
|
||||
this service if you wish), that you receive source code or can get it
|
||||
if you want it, that you can change the software or use pieces of it
|
||||
in new free programs; and that you know you can do these things.
|
||||
|
||||
To protect your rights, we need to make restrictions that forbid
|
||||
anyone to deny you these rights or to ask you to surrender the rights.
|
||||
These restrictions translate to certain responsibilities for you if you
|
||||
distribute copies of the software, or if you modify it.
|
||||
|
||||
For example, if you distribute copies of such a program, whether
|
||||
gratis or for a fee, you must give the recipients all the rights that
|
||||
you have. You must make sure that they, too, receive or can get the
|
||||
source code. And you must show them these terms so they know their
|
||||
rights.
|
||||
|
||||
We protect your rights with two steps: (1) copyright the software, and
|
||||
(2) offer you this license which gives you legal permission to copy,
|
||||
distribute and/or modify the software.
|
||||
|
||||
Also, for each author's protection and ours, we want to make certain
|
||||
that everyone understands that there is no warranty for this free
|
||||
software. If the software is modified by someone else and passed on, we
|
||||
want its recipients to know that what they have is not the original, so
|
||||
that any problems introduced by others will not reflect on the original
|
||||
authors' reputations.
|
||||
|
||||
Finally, any free program is threatened constantly by software
|
||||
patents. We wish to avoid the danger that redistributors of a free
|
||||
program will individually obtain patent licenses, in effect making the
|
||||
program proprietary. To prevent this, we have made it clear that any
|
||||
patent must be licensed for everyone's free use or not licensed at all.
|
||||
|
||||
The precise terms and conditions for copying, distribution and
|
||||
modification follow.
|
||||
|
||||
GNU GENERAL PUBLIC LICENSE
|
||||
TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
||||
|
||||
0. This License applies to any program or other work which contains
|
||||
a notice placed by the copyright holder saying it may be distributed
|
||||
under the terms of this General Public License. The "Program", below,
|
||||
refers to any such program or work, and a "work based on the Program"
|
||||
means either the Program or any derivative work under copyright law:
|
||||
that is to say, a work containing the Program or a portion of it,
|
||||
either verbatim or with modifications and/or translated into another
|
||||
language. (Hereinafter, translation is included without limitation in
|
||||
the term "modification".) Each licensee is addressed as "you".
|
||||
|
||||
Activities other than copying, distribution and modification are not
|
||||
covered by this License; they are outside its scope. The act of
|
||||
running the Program is not restricted, and the output from the Program
|
||||
is covered only if its contents constitute a work based on the
|
||||
Program (independent of having been made by running the Program).
|
||||
Whether that is true depends on what the Program does.
|
||||
|
||||
1. You may copy and distribute verbatim copies of the Program's
|
||||
source code as you receive it, in any medium, provided that you
|
||||
conspicuously and appropriately publish on each copy an appropriate
|
||||
copyright notice and disclaimer of warranty; keep intact all the
|
||||
notices that refer to this License and to the absence of any warranty;
|
||||
and give any other recipients of the Program a copy of this License
|
||||
along with the Program.
|
||||
|
||||
You may charge a fee for the physical act of transferring a copy, and
|
||||
you may at your option offer warranty protection in exchange for a fee.
|
||||
|
||||
2. You may modify your copy or copies of the Program or any portion
|
||||
of it, thus forming a work based on the Program, and copy and
|
||||
distribute such modifications or work under the terms of Section 1
|
||||
above, provided that you also meet all of these conditions:
|
||||
|
||||
a) You must cause the modified files to carry prominent notices
|
||||
stating that you changed the files and the date of any change.
|
||||
|
||||
b) You must cause any work that you distribute or publish, that in
|
||||
whole or in part contains or is derived from the Program or any
|
||||
part thereof, to be licensed as a whole at no charge to all third
|
||||
parties under the terms of this License.
|
||||
|
||||
c) If the modified program normally reads commands interactively
|
||||
when run, you must cause it, when started running for such
|
||||
interactive use in the most ordinary way, to print or display an
|
||||
announcement including an appropriate copyright notice and a
|
||||
notice that there is no warranty (or else, saying that you provide
|
||||
a warranty) and that users may redistribute the program under
|
||||
these conditions, and telling the user how to view a copy of this
|
||||
License. (Exception: if the Program itself is interactive but
|
||||
does not normally print such an announcement, your work based on
|
||||
the Program is not required to print an announcement.)
|
||||
|
||||
These requirements apply to the modified work as a whole. If
|
||||
identifiable sections of that work are not derived from the Program,
|
||||
and can be reasonably considered independent and separate works in
|
||||
themselves, then this License, and its terms, do not apply to those
|
||||
sections when you distribute them as separate works. But when you
|
||||
distribute the same sections as part of a whole which is a work based
|
||||
on the Program, the distribution of the whole must be on the terms of
|
||||
this License, whose permissions for other licensees extend to the
|
||||
entire whole, and thus to each and every part regardless of who wrote it.
|
||||
|
||||
Thus, it is not the intent of this section to claim rights or contest
|
||||
your rights to work written entirely by you; rather, the intent is to
|
||||
exercise the right to control the distribution of derivative or
|
||||
collective works based on the Program.
|
||||
|
||||
In addition, mere aggregation of another work not based on the Program
|
||||
with the Program (or with a work based on the Program) on a volume of
|
||||
a storage or distribution medium does not bring the other work under
|
||||
the scope of this License.
|
||||
|
||||
3. You may copy and distribute the Program (or a work based on it,
|
||||
under Section 2) in object code or executable form under the terms of
|
||||
Sections 1 and 2 above provided that you also do one of the following:
|
||||
|
||||
a) Accompany it with the complete corresponding machine-readable
|
||||
source code, which must be distributed under the terms of Sections
|
||||
1 and 2 above on a medium customarily used for software interchange; or,
|
||||
|
||||
b) Accompany it with a written offer, valid for at least three
|
||||
years, to give any third party, for a charge no more than your
|
||||
cost of physically performing source distribution, a complete
|
||||
machine-readable copy of the corresponding source code, to be
|
||||
distributed under the terms of Sections 1 and 2 above on a medium
|
||||
customarily used for software interchange; or,
|
||||
|
||||
c) Accompany it with the information you received as to the offer
|
||||
to distribute corresponding source code. (This alternative is
|
||||
allowed only for noncommercial distribution and only if you
|
||||
received the program in object code or executable form with such
|
||||
an offer, in accord with Subsection b above.)
|
||||
|
||||
The source code for a work means the preferred form of the work for
|
||||
making modifications to it. For an executable work, complete source
|
||||
code means all the source code for all modules it contains, plus any
|
||||
associated interface definition files, plus the scripts used to
|
||||
control compilation and installation of the executable. However, as a
|
||||
special exception, the source code distributed need not include
|
||||
anything that is normally distributed (in either source or binary
|
||||
form) with the major components (compiler, kernel, and so on) of the
|
||||
operating system on which the executable runs, unless that component
|
||||
itself accompanies the executable.
|
||||
|
||||
If distribution of executable or object code is made by offering
|
||||
access to copy from a designated place, then offering equivalent
|
||||
access to copy the source code from the same place counts as
|
||||
distribution of the source code, even though third parties are not
|
||||
compelled to copy the source along with the object code.
|
||||
|
||||
4. You may not copy, modify, sublicense, or distribute the Program
|
||||
except as expressly provided under this License. Any attempt
|
||||
otherwise to copy, modify, sublicense or distribute the Program is
|
||||
void, and will automatically terminate your rights under this License.
|
||||
However, parties who have received copies, or rights, from you under
|
||||
this License will not have their licenses terminated so long as such
|
||||
parties remain in full compliance.
|
||||
|
||||
5. You are not required to accept this License, since you have not
|
||||
signed it. However, nothing else grants you permission to modify or
|
||||
distribute the Program or its derivative works. These actions are
|
||||
prohibited by law if you do not accept this License. Therefore, by
|
||||
modifying or distributing the Program (or any work based on the
|
||||
Program), you indicate your acceptance of this License to do so, and
|
||||
all its terms and conditions for copying, distributing or modifying
|
||||
the Program or works based on it.
|
||||
|
||||
6. Each time you redistribute the Program (or any work based on the
|
||||
Program), the recipient automatically receives a license from the
|
||||
original licensor to copy, distribute or modify the Program subject to
|
||||
these terms and conditions. You may not impose any further
|
||||
restrictions on the recipients' exercise of the rights granted herein.
|
||||
You are not responsible for enforcing compliance by third parties to
|
||||
this License.
|
||||
|
||||
7. If, as a consequence of a court judgment or allegation of patent
|
||||
infringement or for any other reason (not limited to patent issues),
|
||||
conditions are imposed on you (whether by court order, agreement or
|
||||
otherwise) that contradict the conditions of this License, they do not
|
||||
excuse you from the conditions of this License. If you cannot
|
||||
distribute so as to satisfy simultaneously your obligations under this
|
||||
License and any other pertinent obligations, then as a consequence you
|
||||
may not distribute the Program at all. For example, if a patent
|
||||
license would not permit royalty-free redistribution of the Program by
|
||||
all those who receive copies directly or indirectly through you, then
|
||||
the only way you could satisfy both it and this License would be to
|
||||
refrain entirely from distribution of the Program.
|
||||
|
||||
If any portion of this section is held invalid or unenforceable under
|
||||
any particular circumstance, the balance of the section is intended to
|
||||
apply and the section as a whole is intended to apply in other
|
||||
circumstances.
|
||||
|
||||
It is not the purpose of this section to induce you to infringe any
|
||||
patents or other property right claims or to contest validity of any
|
||||
such claims; this section has the sole purpose of protecting the
|
||||
integrity of the free software distribution system, which is
|
||||
implemented by public license practices. Many people have made
|
||||
generous contributions to the wide range of software distributed
|
||||
through that system in reliance on consistent application of that
|
||||
system; it is up to the author/donor to decide if he or she is willing
|
||||
to distribute software through any other system and a licensee cannot
|
||||
impose that choice.
|
||||
|
||||
This section is intended to make thoroughly clear what is believed to
|
||||
be a consequence of the rest of this License.
|
||||
|
||||
8. If the distribution and/or use of the Program is restricted in
|
||||
certain countries either by patents or by copyrighted interfaces, the
|
||||
original copyright holder who places the Program under this License
|
||||
may add an explicit geographical distribution limitation excluding
|
||||
those countries, so that distribution is permitted only in or among
|
||||
countries not thus excluded. In such case, this License incorporates
|
||||
the limitation as if written in the body of this License.
|
||||
|
||||
9. The Free Software Foundation may publish revised and/or new versions
|
||||
of the General Public License from time to time. Such new versions will
|
||||
be similar in spirit to the present version, but may differ in detail to
|
||||
address new problems or concerns.
|
||||
|
||||
Each version is given a distinguishing version number. If the Program
|
||||
specifies a version number of this License which applies to it and "any
|
||||
later version", you have the option of following the terms and conditions
|
||||
either of that version or of any later version published by the Free
|
||||
Software Foundation. If the Program does not specify a version number of
|
||||
this License, you may choose any version ever published by the Free Software
|
||||
Foundation.
|
||||
|
||||
10. If you wish to incorporate parts of the Program into other free
|
||||
programs whose distribution conditions are different, write to the author
|
||||
to ask for permission. For software which is copyrighted by the Free
|
||||
Software Foundation, write to the Free Software Foundation; we sometimes
|
||||
make exceptions for this. Our decision will be guided by the two goals
|
||||
of preserving the free status of all derivatives of our free software and
|
||||
of promoting the sharing and reuse of software generally.
|
||||
|
||||
NO WARRANTY
|
||||
|
||||
11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
|
||||
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
|
||||
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
|
||||
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
|
||||
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
||||
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
|
||||
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
|
||||
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
|
||||
REPAIR OR CORRECTION.
|
||||
|
||||
12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
|
||||
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
|
||||
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
|
||||
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
|
||||
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
|
||||
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
|
||||
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
|
||||
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
|
||||
POSSIBILITY OF SUCH DAMAGES.
|
||||
@ -1,4 +1,4 @@
|
||||
[state: 04-09-2010]
|
||||
[state: 21-11-2010]
|
||||
|
||||
BATMAN-ADV
|
||||
----------
|
||||
@ -67,7 +67,8 @@ All mesh wide settings can be found in batman's own interface
|
||||
folder:
|
||||
|
||||
# ls /sys/class/net/bat0/mesh/
|
||||
# aggregated_ogms bonding orig_interval vis_mode
|
||||
# aggregated_ogms bonding fragmentation orig_interval
|
||||
# vis_mode
|
||||
|
||||
|
||||
There is a special folder for debugging informations:
|
||||
@ -237,4 +238,3 @@ You can also contact the Authors:
|
||||
|
||||
Marek Lindner <lindner_marek@yahoo.de>
|
||||
Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
|
||||
|
||||
@ -49,7 +49,8 @@ Table of Contents
|
||||
3.3 Configuring Bonding Manually with Ifenslave
|
||||
3.3.1 Configuring Multiple Bonds Manually
|
||||
3.4 Configuring Bonding Manually via Sysfs
|
||||
3.5 Overriding Configuration for Special Cases
|
||||
3.5 Configuration with Interfaces Support
|
||||
3.6 Overriding Configuration for Special Cases
|
||||
|
||||
4. Querying Bonding Configuration
|
||||
4.1 Bonding Configuration
|
||||
@ -161,8 +162,8 @@ onwards) do not have /usr/include/linux symbolically linked to the
|
||||
default kernel source include directory.
|
||||
|
||||
SECOND IMPORTANT NOTE:
|
||||
If you plan to configure bonding using sysfs, you do not need
|
||||
to use ifenslave.
|
||||
If you plan to configure bonding using sysfs or using the
|
||||
/etc/network/interfaces file, you do not need to use ifenslave.
|
||||
|
||||
2. Bonding Driver Options
|
||||
=========================
|
||||
@ -779,22 +780,26 @@ resend_igmp
|
||||
|
||||
You can configure bonding using either your distro's network
|
||||
initialization scripts, or manually using either ifenslave or the
|
||||
sysfs interface. Distros generally use one of two packages for the
|
||||
network initialization scripts: initscripts or sysconfig. Recent
|
||||
versions of these packages have support for bonding, while older
|
||||
sysfs interface. Distros generally use one of three packages for the
|
||||
network initialization scripts: initscripts, sysconfig or interfaces.
|
||||
Recent versions of these packages have support for bonding, while older
|
||||
versions do not.
|
||||
|
||||
We will first describe the options for configuring bonding for
|
||||
distros using versions of initscripts and sysconfig with full or
|
||||
partial support for bonding, then provide information on enabling
|
||||
distros using versions of initscripts, sysconfig and interfaces with full
|
||||
or partial support for bonding, then provide information on enabling
|
||||
bonding without support from the network initialization scripts (i.e.,
|
||||
older versions of initscripts or sysconfig).
|
||||
|
||||
If you're unsure whether your distro uses sysconfig or
|
||||
initscripts, or don't know if it's new enough, have no fear.
|
||||
If you're unsure whether your distro uses sysconfig,
|
||||
initscripts or interfaces, or don't know if it's new enough, have no fear.
|
||||
Determining this is fairly straightforward.
|
||||
|
||||
First, issue the command:
|
||||
First, look for a file called interfaces in /etc/network directory.
|
||||
If this file is present in your system, then your system use interfaces. See
|
||||
Configuration with Interfaces Support.
|
||||
|
||||
Else, issue the command:
|
||||
|
||||
$ rpm -qf /sbin/ifup
|
||||
|
||||
@ -1327,8 +1332,62 @@ echo 2000 > /sys/class/net/bond1/bonding/arp_interval
|
||||
echo +eth2 > /sys/class/net/bond1/bonding/slaves
|
||||
echo +eth3 > /sys/class/net/bond1/bonding/slaves
|
||||
|
||||
3.5 Overriding Configuration for Special Cases
|
||||
3.5 Configuration with Interfaces Support
|
||||
-----------------------------------------
|
||||
|
||||
This section applies to distros which use /etc/network/interfaces file
|
||||
to describe network interface configuration, most notably Debian and it's
|
||||
derivatives.
|
||||
|
||||
The ifup and ifdown commands on Debian don't support bonding out of
|
||||
the box. The ifenslave-2.6 package should be installed to provide bonding
|
||||
support. Once installed, this package will provide bond-* options to be used
|
||||
into /etc/network/interfaces.
|
||||
|
||||
Note that ifenslave-2.6 package will load the bonding module and use
|
||||
the ifenslave command when appropriate.
|
||||
|
||||
Example Configurations
|
||||
----------------------
|
||||
|
||||
In /etc/network/interfaces, the following stanza will configure bond0, in
|
||||
active-backup mode, with eth0 and eth1 as slaves.
|
||||
|
||||
auto bond0
|
||||
iface bond0 inet dhcp
|
||||
bond-slaves eth0 eth1
|
||||
bond-mode active-backup
|
||||
bond-miimon 100
|
||||
bond-primary eth0 eth1
|
||||
|
||||
If the above configuration doesn't work, you might have a system using
|
||||
upstart for system startup. This is most notably true for recent
|
||||
Ubuntu versions. The following stanza in /etc/network/interfaces will
|
||||
produce the same result on those systems.
|
||||
|
||||
auto bond0
|
||||
iface bond0 inet dhcp
|
||||
bond-slaves none
|
||||
bond-mode active-backup
|
||||
bond-miimon 100
|
||||
|
||||
auto eth0
|
||||
iface eth0 inet manual
|
||||
bond-master bond0
|
||||
bond-primary eth0 eth1
|
||||
|
||||
auto eth1
|
||||
iface eth1 inet manual
|
||||
bond-master bond0
|
||||
bond-primary eth0 eth1
|
||||
|
||||
For a full list of bond-* supported options in /etc/network/interfaces and some
|
||||
more advanced examples tailored to you particular distros, see the files in
|
||||
/usr/share/doc/ifenslave-2.6.
|
||||
|
||||
3.6 Overriding Configuration for Special Cases
|
||||
----------------------------------------------
|
||||
|
||||
When using the bonding driver, the physical port which transmits a frame is
|
||||
typically selected by the bonding driver, and is not relevant to the user or
|
||||
system administrator. The output port is simply selected using the policies of
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
In order to use the Ethernet bridging functionality, you'll need the
|
||||
userspace tools. These programs and documentation are available
|
||||
at http://www.linux-foundation.org/en/Net:Bridge. The download page is
|
||||
at http://www.linuxfoundation.org/en/Net:Bridge. The download page is
|
||||
http://prdownloads.sourceforge.net/bridge.
|
||||
|
||||
If you still have questions, don't hesitate to post to the mailing list
|
||||
(more info http://lists.osdl.org/mailman/listinfo/bridge).
|
||||
(more info https://lists.linux-foundation.org/mailman/listinfo/bridge).
|
||||
|
||||
|
||||
@ -32,7 +32,7 @@ the physical hardware, both with regard to SPI and to GPIOs.
|
||||
This function is called by the CAIF SPI interface to give
|
||||
you a chance to set up your hardware to be ready to receive
|
||||
a stream of data from the master. The xfer structure contains
|
||||
both physical and logical adresses, as well as the total length
|
||||
both physical and logical addresses, as well as the total length
|
||||
of the transfer in both directions.The dev parameter can be used
|
||||
to map to different CAIF SPI slave devices.
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user