Merge branch 'linus' into irq/genirq
This commit is contained in:
Коммит
5a2dd72abd
1
.mailmap
1
.mailmap
|
@ -32,6 +32,7 @@ Christoph Hellwig <hch@lst.de>
|
||||||
Corey Minyard <minyard@acm.org>
|
Corey Minyard <minyard@acm.org>
|
||||||
David Brownell <david-b@pacbell.net>
|
David Brownell <david-b@pacbell.net>
|
||||||
David Woodhouse <dwmw2@shinybook.infradead.org>
|
David Woodhouse <dwmw2@shinybook.infradead.org>
|
||||||
|
Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
|
||||||
Domen Puncer <domen@coderock.org>
|
Domen Puncer <domen@coderock.org>
|
||||||
Douglas Gilbert <dougg@torque.net>
|
Douglas Gilbert <dougg@torque.net>
|
||||||
Ed L. Cashin <ecashin@coraid.com>
|
Ed L. Cashin <ecashin@coraid.com>
|
||||||
|
|
38
CREDITS
38
CREDITS
|
@ -369,10 +369,10 @@ P: 1024/8462A731 4C 55 86 34 44 59 A7 99 2B 97 88 4A 88 9A 0D 97
|
||||||
D: sun4 port, Sparc hacker
|
D: sun4 port, Sparc hacker
|
||||||
|
|
||||||
N: Hugh Blemings
|
N: Hugh Blemings
|
||||||
E: hugh@misc.nu
|
E: hugh@blemings.org
|
||||||
W: http://misc.nu/hugh/
|
W: http://blemings.org/hugh
|
||||||
D: Author and maintainer of the Keyspan USB to Serial drivers
|
D: Original author of the Keyspan USB to serial drivers, random PowerPC hacker
|
||||||
S: Po Box 234
|
S: PO Box 234
|
||||||
S: Belconnen ACT 2616
|
S: Belconnen ACT 2616
|
||||||
S: Australia
|
S: Australia
|
||||||
|
|
||||||
|
@ -464,6 +464,11 @@ S: 1200 Goldenrod Dr.
|
||||||
S: Nampa, Idaho 83686
|
S: Nampa, Idaho 83686
|
||||||
S: USA
|
S: USA
|
||||||
|
|
||||||
|
N: Dirk J. Brandewie
|
||||||
|
E: dirk.j.brandewie@intel.com
|
||||||
|
E: linux-wimax@intel.com
|
||||||
|
D: Intel Wireless WiMAX Connection 2400 SDIO driver
|
||||||
|
|
||||||
N: Derrick J. Brashear
|
N: Derrick J. Brashear
|
||||||
E: shadow@dementia.org
|
E: shadow@dementia.org
|
||||||
W: http://www.dementia.org/~shadow
|
W: http://www.dementia.org/~shadow
|
||||||
|
@ -1681,7 +1686,7 @@ E: ajoshi@shell.unixbox.com
|
||||||
D: fbdev hacking
|
D: fbdev hacking
|
||||||
|
|
||||||
N: Jesper Juhl
|
N: Jesper Juhl
|
||||||
E: jesper.juhl@gmail.com
|
E: jj@chaosbits.net
|
||||||
D: Various fixes, cleanups and minor features all over the tree.
|
D: Various fixes, cleanups and minor features all over the tree.
|
||||||
D: Wrote initial version of the hdaps driver (since passed on to others).
|
D: Wrote initial version of the hdaps driver (since passed on to others).
|
||||||
S: Lemnosvej 1, 3.tv
|
S: Lemnosvej 1, 3.tv
|
||||||
|
@ -2119,6 +2124,11 @@ N: H.J. Lu
|
||||||
E: hjl@gnu.ai.mit.edu
|
E: hjl@gnu.ai.mit.edu
|
||||||
D: GCC + libraries hacker
|
D: GCC + libraries hacker
|
||||||
|
|
||||||
|
N: Yanir Lubetkin
|
||||||
|
E: yanirx.lubatkin@intel.com
|
||||||
|
E: linux-wimax@intel.com
|
||||||
|
D: Intel Wireless WiMAX Connection 2400 driver
|
||||||
|
|
||||||
N: Michal Ludvig
|
N: Michal Ludvig
|
||||||
E: michal@logix.cz
|
E: michal@logix.cz
|
||||||
E: michal.ludvig@asterisk.co.nz
|
E: michal.ludvig@asterisk.co.nz
|
||||||
|
@ -2693,6 +2703,13 @@ S: RR #5, 497 Pole Line Road
|
||||||
S: Thunder Bay, Ontario
|
S: Thunder Bay, Ontario
|
||||||
S: CANADA P7C 5M9
|
S: CANADA P7C 5M9
|
||||||
|
|
||||||
|
N: Inaky Perez-Gonzalez
|
||||||
|
E: inaky.perez-gonzalez@intel.com
|
||||||
|
E: linux-wimax@intel.com
|
||||||
|
E: inakypg@yahoo.com
|
||||||
|
D: WiMAX stack
|
||||||
|
D: Intel Wireless WiMAX Connection 2400 driver
|
||||||
|
|
||||||
N: Yuri Per
|
N: Yuri Per
|
||||||
E: yuri@pts.mipt.ru
|
E: yuri@pts.mipt.ru
|
||||||
D: Some smbfs fixes
|
D: Some smbfs fixes
|
||||||
|
@ -3769,14 +3786,11 @@ S: The Netherlands
|
||||||
|
|
||||||
N: David Woodhouse
|
N: David Woodhouse
|
||||||
E: dwmw2@infradead.org
|
E: dwmw2@infradead.org
|
||||||
D: ARCnet stuff, Applicom board driver, SO_BINDTODEVICE,
|
D: JFFS2 file system, Memory Technology Device subsystem,
|
||||||
D: some Alpha platform porting from 2.0, Memory Technology Devices,
|
|
||||||
D: Acquire watchdog timer, PC speaker driver maintenance,
|
|
||||||
D: various other stuff that annoyed me by not working.
|
D: various other stuff that annoyed me by not working.
|
||||||
S: c/o Red Hat Engineering
|
S: c/o Intel Corporation
|
||||||
S: Rustat House
|
S: Pipers Way
|
||||||
S: 60 Clifton Road
|
S: Swindon. SN3 1RJ
|
||||||
S: Cambridge. CB1 7EG
|
|
||||||
S: England
|
S: England
|
||||||
|
|
||||||
N: Chris Wright
|
N: Chris Wright
|
||||||
|
|
|
@ -3,8 +3,9 @@ Date: April 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
state. This holds the regulator output state.
|
state. This reports the regulator enable status, for
|
||||||
|
regulators which can report that value.
|
||||||
|
|
||||||
This will be one of the following strings:
|
This will be one of the following strings:
|
||||||
|
|
||||||
|
@ -18,7 +19,8 @@ Description:
|
||||||
'disabled' means the regulator output is OFF and is not
|
'disabled' means the regulator output is OFF and is not
|
||||||
supplying power to the system..
|
supplying power to the system..
|
||||||
|
|
||||||
'unknown' means software cannot determine the state.
|
'unknown' means software cannot determine the state, or
|
||||||
|
the reported state is invalid.
|
||||||
|
|
||||||
NOTE: this field can be used in conjunction with microvolts
|
NOTE: this field can be used in conjunction with microvolts
|
||||||
and microamps to determine regulator output levels.
|
and microamps to determine regulator output levels.
|
||||||
|
@ -53,9 +55,10 @@ Date: April 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
microvolts. This holds the regulator output voltage setting
|
microvolts. This holds the regulator output voltage setting
|
||||||
measured in microvolts (i.e. E-6 Volts).
|
measured in microvolts (i.e. E-6 Volts), for regulators
|
||||||
|
which can report that voltage.
|
||||||
|
|
||||||
NOTE: This value should not be used to determine the regulator
|
NOTE: This value should not be used to determine the regulator
|
||||||
output voltage level as this value is the same regardless of
|
output voltage level as this value is the same regardless of
|
||||||
|
@ -67,9 +70,10 @@ Date: April 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
microamps. This holds the regulator output current limit
|
microamps. This holds the regulator output current limit
|
||||||
setting measured in microamps (i.e. E-6 Amps).
|
setting measured in microamps (i.e. E-6 Amps), for regulators
|
||||||
|
which can report that current.
|
||||||
|
|
||||||
NOTE: This value should not be used to determine the regulator
|
NOTE: This value should not be used to determine the regulator
|
||||||
output current level as this value is the same regardless of
|
output current level as this value is the same regardless of
|
||||||
|
@ -81,8 +85,9 @@ Date: April 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
opmode. This holds the regulator operating mode setting.
|
opmode. This holds the current regulator operating mode,
|
||||||
|
for regulators which can report it.
|
||||||
|
|
||||||
The opmode value can be one of the following strings:
|
The opmode value can be one of the following strings:
|
||||||
|
|
||||||
|
@ -92,7 +97,7 @@ Description:
|
||||||
'standby'
|
'standby'
|
||||||
'unknown'
|
'unknown'
|
||||||
|
|
||||||
The modes are described in include/linux/regulator/regulator.h
|
The modes are described in include/linux/regulator/consumer.h
|
||||||
|
|
||||||
NOTE: This value should not be used to determine the regulator
|
NOTE: This value should not be used to determine the regulator
|
||||||
output operating mode as this value is the same regardless of
|
output operating mode as this value is the same regardless of
|
||||||
|
@ -104,9 +109,10 @@ Date: April 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
min_microvolts. This holds the minimum safe working regulator
|
min_microvolts. This holds the minimum safe working regulator
|
||||||
output voltage setting for this domain measured in microvolts.
|
output voltage setting for this domain measured in microvolts,
|
||||||
|
for regulators which support voltage constraints.
|
||||||
|
|
||||||
NOTE: this will return the string 'constraint not defined' if
|
NOTE: this will return the string 'constraint not defined' if
|
||||||
the power domain has no min microvolts constraint defined by
|
the power domain has no min microvolts constraint defined by
|
||||||
|
@ -118,9 +124,10 @@ Date: April 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
max_microvolts. This holds the maximum safe working regulator
|
max_microvolts. This holds the maximum safe working regulator
|
||||||
output voltage setting for this domain measured in microvolts.
|
output voltage setting for this domain measured in microvolts,
|
||||||
|
for regulators which support voltage constraints.
|
||||||
|
|
||||||
NOTE: this will return the string 'constraint not defined' if
|
NOTE: this will return the string 'constraint not defined' if
|
||||||
the power domain has no max microvolts constraint defined by
|
the power domain has no max microvolts constraint defined by
|
||||||
|
@ -132,10 +139,10 @@ Date: April 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
min_microamps. This holds the minimum safe working regulator
|
min_microamps. This holds the minimum safe working regulator
|
||||||
output current limit setting for this domain measured in
|
output current limit setting for this domain measured in
|
||||||
microamps.
|
microamps, for regulators which support current constraints.
|
||||||
|
|
||||||
NOTE: this will return the string 'constraint not defined' if
|
NOTE: this will return the string 'constraint not defined' if
|
||||||
the power domain has no min microamps constraint defined by
|
the power domain has no min microamps constraint defined by
|
||||||
|
@ -147,10 +154,10 @@ Date: April 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
max_microamps. This holds the maximum safe working regulator
|
max_microamps. This holds the maximum safe working regulator
|
||||||
output current limit setting for this domain measured in
|
output current limit setting for this domain measured in
|
||||||
microamps.
|
microamps, for regulators which support current constraints.
|
||||||
|
|
||||||
NOTE: this will return the string 'constraint not defined' if
|
NOTE: this will return the string 'constraint not defined' if
|
||||||
the power domain has no max microamps constraint defined by
|
the power domain has no max microamps constraint defined by
|
||||||
|
@ -185,7 +192,7 @@ Date: April 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
requested_microamps. This holds the total requested load
|
requested_microamps. This holds the total requested load
|
||||||
current in microamps for this regulator from all its consumer
|
current in microamps for this regulator from all its consumer
|
||||||
devices.
|
devices.
|
||||||
|
@ -204,125 +211,102 @@ Date: May 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
suspend_mem_microvolts. This holds the regulator output
|
suspend_mem_microvolts. This holds the regulator output
|
||||||
voltage setting for this domain measured in microvolts when
|
voltage setting for this domain measured in microvolts when
|
||||||
the system is suspended to memory.
|
the system is suspended to memory, for voltage regulators
|
||||||
|
implementing suspend voltage configuration constraints.
|
||||||
NOTE: this will return the string 'not defined' if
|
|
||||||
the power domain has no suspend to memory voltage defined by
|
|
||||||
platform code.
|
|
||||||
|
|
||||||
What: /sys/class/regulator/.../suspend_disk_microvolts
|
What: /sys/class/regulator/.../suspend_disk_microvolts
|
||||||
Date: May 2008
|
Date: May 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
suspend_disk_microvolts. This holds the regulator output
|
suspend_disk_microvolts. This holds the regulator output
|
||||||
voltage setting for this domain measured in microvolts when
|
voltage setting for this domain measured in microvolts when
|
||||||
the system is suspended to disk.
|
the system is suspended to disk, for voltage regulators
|
||||||
|
implementing suspend voltage configuration constraints.
|
||||||
NOTE: this will return the string 'not defined' if
|
|
||||||
the power domain has no suspend to disk voltage defined by
|
|
||||||
platform code.
|
|
||||||
|
|
||||||
What: /sys/class/regulator/.../suspend_standby_microvolts
|
What: /sys/class/regulator/.../suspend_standby_microvolts
|
||||||
Date: May 2008
|
Date: May 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
suspend_standby_microvolts. This holds the regulator output
|
suspend_standby_microvolts. This holds the regulator output
|
||||||
voltage setting for this domain measured in microvolts when
|
voltage setting for this domain measured in microvolts when
|
||||||
the system is suspended to standby.
|
the system is suspended to standby, for voltage regulators
|
||||||
|
implementing suspend voltage configuration constraints.
|
||||||
NOTE: this will return the string 'not defined' if
|
|
||||||
the power domain has no suspend to standby voltage defined by
|
|
||||||
platform code.
|
|
||||||
|
|
||||||
What: /sys/class/regulator/.../suspend_mem_mode
|
What: /sys/class/regulator/.../suspend_mem_mode
|
||||||
Date: May 2008
|
Date: May 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
suspend_mem_mode. This holds the regulator operating mode
|
suspend_mem_mode. This holds the regulator operating mode
|
||||||
setting for this domain when the system is suspended to
|
setting for this domain when the system is suspended to
|
||||||
memory.
|
memory, for regulators implementing suspend mode
|
||||||
|
configuration constraints.
|
||||||
NOTE: this will return the string 'not defined' if
|
|
||||||
the power domain has no suspend to memory mode defined by
|
|
||||||
platform code.
|
|
||||||
|
|
||||||
What: /sys/class/regulator/.../suspend_disk_mode
|
What: /sys/class/regulator/.../suspend_disk_mode
|
||||||
Date: May 2008
|
Date: May 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
suspend_disk_mode. This holds the regulator operating mode
|
suspend_disk_mode. This holds the regulator operating mode
|
||||||
setting for this domain when the system is suspended to disk.
|
setting for this domain when the system is suspended to disk,
|
||||||
|
for regulators implementing suspend mode configuration
|
||||||
NOTE: this will return the string 'not defined' if
|
constraints.
|
||||||
the power domain has no suspend to disk mode defined by
|
|
||||||
platform code.
|
|
||||||
|
|
||||||
What: /sys/class/regulator/.../suspend_standby_mode
|
What: /sys/class/regulator/.../suspend_standby_mode
|
||||||
Date: May 2008
|
Date: May 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
suspend_standby_mode. This holds the regulator operating mode
|
suspend_standby_mode. This holds the regulator operating mode
|
||||||
setting for this domain when the system is suspended to
|
setting for this domain when the system is suspended to
|
||||||
standby.
|
standby, for regulators implementing suspend mode
|
||||||
|
configuration constraints.
|
||||||
NOTE: this will return the string 'not defined' if
|
|
||||||
the power domain has no suspend to standby mode defined by
|
|
||||||
platform code.
|
|
||||||
|
|
||||||
What: /sys/class/regulator/.../suspend_mem_state
|
What: /sys/class/regulator/.../suspend_mem_state
|
||||||
Date: May 2008
|
Date: May 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
suspend_mem_state. This holds the regulator operating state
|
suspend_mem_state. This holds the regulator operating state
|
||||||
when suspended to memory.
|
when suspended to memory, for regulators implementing suspend
|
||||||
|
configuration constraints.
|
||||||
|
|
||||||
This will be one of the following strings:
|
This will be one of the same strings reported by
|
||||||
|
the "state" attribute.
|
||||||
'enabled'
|
|
||||||
'disabled'
|
|
||||||
'not defined'
|
|
||||||
|
|
||||||
What: /sys/class/regulator/.../suspend_disk_state
|
What: /sys/class/regulator/.../suspend_disk_state
|
||||||
Date: May 2008
|
Date: May 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
suspend_disk_state. This holds the regulator operating state
|
suspend_disk_state. This holds the regulator operating state
|
||||||
when suspended to disk.
|
when suspended to disk, for regulators implementing
|
||||||
|
suspend configuration constraints.
|
||||||
|
|
||||||
This will be one of the following strings:
|
This will be one of the same strings reported by
|
||||||
|
the "state" attribute.
|
||||||
'enabled'
|
|
||||||
'disabled'
|
|
||||||
'not defined'
|
|
||||||
|
|
||||||
What: /sys/class/regulator/.../suspend_standby_state
|
What: /sys/class/regulator/.../suspend_standby_state
|
||||||
Date: May 2008
|
Date: May 2008
|
||||||
KernelVersion: 2.6.26
|
KernelVersion: 2.6.26
|
||||||
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
Contact: Liam Girdwood <lrg@slimlogic.co.uk>
|
||||||
Description:
|
Description:
|
||||||
Each regulator directory will contain a field called
|
Some regulator directories will contain a field called
|
||||||
suspend_standby_state. This holds the regulator operating
|
suspend_standby_state. This holds the regulator operating
|
||||||
state when suspended to standby.
|
state when suspended to standby, for regulators implementing
|
||||||
|
suspend configuration constraints.
|
||||||
|
|
||||||
This will be one of the following strings:
|
This will be one of the same strings reported by
|
||||||
|
the "state" attribute.
|
||||||
'enabled'
|
|
||||||
'disabled'
|
|
||||||
'not defined'
|
|
||||||
|
|
|
@ -32,14 +32,16 @@ Contact: linux-usb@vger.kernel.org
|
||||||
Description:
|
Description:
|
||||||
Write:
|
Write:
|
||||||
|
|
||||||
<channel> [<bpst offset>]
|
<channel>
|
||||||
|
|
||||||
to start beaconing on a specific channel, or stop
|
to force a specific channel to be used when beaconing,
|
||||||
beaconing if <channel> is -1. Valid channels depends
|
or, if <channel> is -1, to prohibit beaconing. If
|
||||||
on the radio controller's supported band groups.
|
<channel> is 0, then the default channel selection
|
||||||
|
algorithm will be used. Valid channels depends on the
|
||||||
|
radio controller's supported band groups.
|
||||||
|
|
||||||
<bpst offset> may be used to try and join a specific
|
Reading returns the currently active channel, or -1 if
|
||||||
beacon group if more than one was found during a scan.
|
the radio controller is not beaconing.
|
||||||
|
|
||||||
What: /sys/class/uwb_rc/uwbN/scan
|
What: /sys/class/uwb_rc/uwbN/scan
|
||||||
Date: July 2008
|
Date: July 2008
|
||||||
|
|
|
@ -6,7 +6,6 @@ Description:
|
||||||
internal state of the kernel memory blocks. Files could be
|
internal state of the kernel memory blocks. Files could be
|
||||||
added or removed dynamically to represent hot-add/remove
|
added or removed dynamically to represent hot-add/remove
|
||||||
operations.
|
operations.
|
||||||
|
|
||||||
Users: hotplug memory add/remove tools
|
Users: hotplug memory add/remove tools
|
||||||
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||||
|
|
||||||
|
@ -19,6 +18,56 @@ Description:
|
||||||
This is useful for a user-level agent to determine
|
This is useful for a user-level agent to determine
|
||||||
identify removable sections of the memory before attempting
|
identify removable sections of the memory before attempting
|
||||||
potentially expensive hot-remove memory operation
|
potentially expensive hot-remove memory operation
|
||||||
|
|
||||||
Users: hotplug memory remove tools
|
Users: hotplug memory remove tools
|
||||||
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||||
|
|
||||||
|
What: /sys/devices/system/memory/memoryX/phys_device
|
||||||
|
Date: September 2008
|
||||||
|
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||||
|
Description:
|
||||||
|
The file /sys/devices/system/memory/memoryX/phys_device
|
||||||
|
is read-only and is designed to show the name of physical
|
||||||
|
memory device. Implementation is currently incomplete.
|
||||||
|
|
||||||
|
What: /sys/devices/system/memory/memoryX/phys_index
|
||||||
|
Date: September 2008
|
||||||
|
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||||
|
Description:
|
||||||
|
The file /sys/devices/system/memory/memoryX/phys_index
|
||||||
|
is read-only and contains the section ID in hexadecimal
|
||||||
|
which is equivalent to decimal X contained in the
|
||||||
|
memory section directory name.
|
||||||
|
|
||||||
|
What: /sys/devices/system/memory/memoryX/state
|
||||||
|
Date: September 2008
|
||||||
|
Contact: Badari Pulavarty <pbadari@us.ibm.com>
|
||||||
|
Description:
|
||||||
|
The file /sys/devices/system/memory/memoryX/state
|
||||||
|
is read-write. When read, it's contents show the
|
||||||
|
online/offline state of the memory section. When written,
|
||||||
|
root can toggle the the online/offline state of a removable
|
||||||
|
memory section (see removable file description above)
|
||||||
|
using the following commands.
|
||||||
|
# echo online > /sys/devices/system/memory/memoryX/state
|
||||||
|
# echo offline > /sys/devices/system/memory/memoryX/state
|
||||||
|
|
||||||
|
For example, if /sys/devices/system/memory/memory22/removable
|
||||||
|
contains a value of 1 and
|
||||||
|
/sys/devices/system/memory/memory22/state contains the
|
||||||
|
string "online" the following command can be executed by
|
||||||
|
by root to offline that section.
|
||||||
|
# echo offline > /sys/devices/system/memory/memory22/state
|
||||||
|
Users: hotplug memory remove tools
|
||||||
|
https://w3.opensource.ibm.com/projects/powerpc-utils/
|
||||||
|
|
||||||
|
What: /sys/devices/system/node/nodeX/memoryY
|
||||||
|
Date: September 2008
|
||||||
|
Contact: Gary Hade <garyhade@us.ibm.com>
|
||||||
|
Description:
|
||||||
|
When CONFIG_NUMA is enabled
|
||||||
|
/sys/devices/system/node/nodeX/memoryY is a symbolic link that
|
||||||
|
points to the corresponding /sys/devices/system/memory/memoryY
|
||||||
|
memory section directory. For example, the following symbolic
|
||||||
|
link is created for memory section 9 on node0.
|
||||||
|
/sys/devices/system/node/node0/memory9 -> ../../memory/memory9
|
||||||
|
|
||||||
|
|
|
@ -170,16 +170,15 @@ Returns: 0 if successful and a negative error if not.
|
||||||
u64
|
u64
|
||||||
dma_get_required_mask(struct device *dev)
|
dma_get_required_mask(struct device *dev)
|
||||||
|
|
||||||
After setting the mask with dma_set_mask(), this API returns the
|
This API returns the mask that the platform requires to
|
||||||
actual mask (within that already set) that the platform actually
|
operate efficiently. Usually this means the returned mask
|
||||||
requires to operate efficiently. Usually this means the returned mask
|
|
||||||
is the minimum required to cover all of memory. Examining the
|
is the minimum required to cover all of memory. Examining the
|
||||||
required mask gives drivers with variable descriptor sizes the
|
required mask gives drivers with variable descriptor sizes the
|
||||||
opportunity to use smaller descriptors as necessary.
|
opportunity to use smaller descriptors as necessary.
|
||||||
|
|
||||||
Requesting the required mask does not alter the current mask. If you
|
Requesting the required mask does not alter the current mask. If you
|
||||||
wish to take advantage of it, you should issue another dma_set_mask()
|
wish to take advantage of it, you should issue a dma_set_mask()
|
||||||
call to lower the mask again.
|
call to set the mask to the value returned.
|
||||||
|
|
||||||
|
|
||||||
Part Id - Streaming DMA mappings
|
Part Id - Streaming DMA mappings
|
||||||
|
|
|
@ -26,7 +26,7 @@ mapped only for the time they are actually used and unmapped after the DMA
|
||||||
transfer.
|
transfer.
|
||||||
|
|
||||||
The following API will work of course even on platforms where no such
|
The following API will work of course even on platforms where no such
|
||||||
hardware exists, see e.g. include/asm-i386/pci.h for how it is implemented on
|
hardware exists, see e.g. arch/x86/include/asm/pci.h for how it is implemented on
|
||||||
top of the virt_to_bus interface.
|
top of the virt_to_bus interface.
|
||||||
|
|
||||||
First of all, you should make sure
|
First of all, you should make sure
|
||||||
|
|
|
@ -6,13 +6,13 @@
|
||||||
# To add a new book the only step required is to add the book to the
|
# To add a new book the only step required is to add the book to the
|
||||||
# list of DOCBOOKS.
|
# list of DOCBOOKS.
|
||||||
|
|
||||||
DOCBOOKS := wanbook.xml z8530book.xml mcabook.xml \
|
DOCBOOKS := z8530book.xml mcabook.xml \
|
||||||
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
|
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
|
||||||
procfs-guide.xml writing_usb_driver.xml networking.xml \
|
procfs-guide.xml writing_usb_driver.xml networking.xml \
|
||||||
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
|
kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \
|
||||||
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
|
gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
|
||||||
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
|
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
|
||||||
mac80211.xml debugobjects.xml sh.xml
|
mac80211.xml debugobjects.xml sh.xml regulator.xml
|
||||||
|
|
||||||
###
|
###
|
||||||
# The build process is as follows (targets):
|
# The build process is as follows (targets):
|
||||||
|
|
|
@ -74,6 +74,14 @@
|
||||||
!Enet/sunrpc/rpcb_clnt.c
|
!Enet/sunrpc/rpcb_clnt.c
|
||||||
!Enet/sunrpc/clnt.c
|
!Enet/sunrpc/clnt.c
|
||||||
</sect1>
|
</sect1>
|
||||||
|
<sect1><title>WiMAX</title>
|
||||||
|
!Enet/wimax/op-msg.c
|
||||||
|
!Enet/wimax/op-reset.c
|
||||||
|
!Enet/wimax/op-rfkill.c
|
||||||
|
!Enet/wimax/stack.c
|
||||||
|
!Iinclude/net/wimax.h
|
||||||
|
!Iinclude/linux/wimax.h
|
||||||
|
</sect1>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
<chapter id="netdev">
|
<chapter id="netdev">
|
||||||
|
@ -98,9 +106,6 @@
|
||||||
X!Enet/core/wireless.c
|
X!Enet/core/wireless.c
|
||||||
</sect1>
|
</sect1>
|
||||||
-->
|
-->
|
||||||
<sect1><title>Synchronous PPP</title>
|
|
||||||
!Edrivers/net/wan/syncppp.c
|
|
||||||
</sect1>
|
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
</book>
|
</book>
|
||||||
|
|
|
@ -0,0 +1,304 @@
|
||||||
|
<?xml version="1.0" encoding="UTF-8"?>
|
||||||
|
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||||
|
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
||||||
|
|
||||||
|
<book id="regulator-api">
|
||||||
|
<bookinfo>
|
||||||
|
<title>Voltage and current regulator API</title>
|
||||||
|
|
||||||
|
<authorgroup>
|
||||||
|
<author>
|
||||||
|
<firstname>Liam</firstname>
|
||||||
|
<surname>Girdwood</surname>
|
||||||
|
<affiliation>
|
||||||
|
<address>
|
||||||
|
<email>lrg@slimlogic.co.uk</email>
|
||||||
|
</address>
|
||||||
|
</affiliation>
|
||||||
|
</author>
|
||||||
|
<author>
|
||||||
|
<firstname>Mark</firstname>
|
||||||
|
<surname>Brown</surname>
|
||||||
|
<affiliation>
|
||||||
|
<orgname>Wolfson Microelectronics</orgname>
|
||||||
|
<address>
|
||||||
|
<email>broonie@opensource.wolfsonmicro.com</email>
|
||||||
|
</address>
|
||||||
|
</affiliation>
|
||||||
|
</author>
|
||||||
|
</authorgroup>
|
||||||
|
|
||||||
|
<copyright>
|
||||||
|
<year>2007-2008</year>
|
||||||
|
<holder>Wolfson Microelectronics</holder>
|
||||||
|
</copyright>
|
||||||
|
<copyright>
|
||||||
|
<year>2008</year>
|
||||||
|
<holder>Liam Girdwood</holder>
|
||||||
|
</copyright>
|
||||||
|
|
||||||
|
<legalnotice>
|
||||||
|
<para>
|
||||||
|
This documentation is free software; you can redistribute
|
||||||
|
it and/or modify it under the terms of the GNU General Public
|
||||||
|
License version 2 as published by the Free Software Foundation.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
This program is distributed in the hope that it will be
|
||||||
|
useful, but WITHOUT ANY WARRANTY; without even the implied
|
||||||
|
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
||||||
|
See the GNU General Public License for more details.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
You should have received a copy of the GNU General Public
|
||||||
|
License along with this program; if not, write to the Free
|
||||||
|
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
|
||||||
|
MA 02111-1307 USA
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
For more details see the file COPYING in the source
|
||||||
|
distribution of Linux.
|
||||||
|
</para>
|
||||||
|
</legalnotice>
|
||||||
|
</bookinfo>
|
||||||
|
|
||||||
|
<toc></toc>
|
||||||
|
|
||||||
|
<chapter id="intro">
|
||||||
|
<title>Introduction</title>
|
||||||
|
<para>
|
||||||
|
This framework is designed to provide a standard kernel
|
||||||
|
interface to control voltage and current regulators.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
The intention is to allow systems to dynamically control
|
||||||
|
regulator power output in order to save power and prolong
|
||||||
|
battery life. This applies to both voltage regulators (where
|
||||||
|
voltage output is controllable) and current sinks (where current
|
||||||
|
limit is controllable).
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Note that additional (and currently more complete) documentation
|
||||||
|
is available in the Linux kernel source under
|
||||||
|
<filename>Documentation/power/regulator</filename>.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<sect1 id="glossary">
|
||||||
|
<title>Glossary</title>
|
||||||
|
<para>
|
||||||
|
The regulator API uses a number of terms which may not be
|
||||||
|
familiar:
|
||||||
|
</para>
|
||||||
|
<glossary>
|
||||||
|
|
||||||
|
<glossentry>
|
||||||
|
<glossterm>Regulator</glossterm>
|
||||||
|
<glossdef>
|
||||||
|
<para>
|
||||||
|
Electronic device that supplies power to other devices. Most
|
||||||
|
regulators can enable and disable their output and some can also
|
||||||
|
control their output voltage or current.
|
||||||
|
</para>
|
||||||
|
</glossdef>
|
||||||
|
</glossentry>
|
||||||
|
|
||||||
|
<glossentry>
|
||||||
|
<glossterm>Consumer</glossterm>
|
||||||
|
<glossdef>
|
||||||
|
<para>
|
||||||
|
Electronic device which consumes power provided by a regulator.
|
||||||
|
These may either be static, requiring only a fixed supply, or
|
||||||
|
dynamic, requiring active management of the regulator at
|
||||||
|
runtime.
|
||||||
|
</para>
|
||||||
|
</glossdef>
|
||||||
|
</glossentry>
|
||||||
|
|
||||||
|
<glossentry>
|
||||||
|
<glossterm>Power Domain</glossterm>
|
||||||
|
<glossdef>
|
||||||
|
<para>
|
||||||
|
The electronic circuit supplied by a given regulator, including
|
||||||
|
the regulator and all consumer devices. The configuration of
|
||||||
|
the regulator is shared between all the components in the
|
||||||
|
circuit.
|
||||||
|
</para>
|
||||||
|
</glossdef>
|
||||||
|
</glossentry>
|
||||||
|
|
||||||
|
<glossentry>
|
||||||
|
<glossterm>Power Management Integrated Circuit</glossterm>
|
||||||
|
<acronym>PMIC</acronym>
|
||||||
|
<glossdef>
|
||||||
|
<para>
|
||||||
|
An IC which contains numerous regulators and often also other
|
||||||
|
subsystems. In an embedded system the primary PMIC is often
|
||||||
|
equivalent to a combination of the PSU and southbridge in a
|
||||||
|
desktop system.
|
||||||
|
</para>
|
||||||
|
</glossdef>
|
||||||
|
</glossentry>
|
||||||
|
</glossary>
|
||||||
|
</sect1>
|
||||||
|
</chapter>
|
||||||
|
|
||||||
|
<chapter id="consumer">
|
||||||
|
<title>Consumer driver interface</title>
|
||||||
|
<para>
|
||||||
|
This offers a similar API to the kernel clock framework.
|
||||||
|
Consumer drivers use <link
|
||||||
|
linkend='API-regulator-get'>get</link> and <link
|
||||||
|
linkend='API-regulator-put'>put</link> operations to acquire and
|
||||||
|
release regulators. Functions are
|
||||||
|
provided to <link linkend='API-regulator-enable'>enable</link>
|
||||||
|
and <link linkend='API-regulator-disable'>disable</link> the
|
||||||
|
reguator and to get and set the runtime parameters of the
|
||||||
|
regulator.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
When requesting regulators consumers use symbolic names for their
|
||||||
|
supplies, such as "Vcc", which are mapped into actual regulator
|
||||||
|
devices by the machine interface.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
A stub version of this API is provided when the regulator
|
||||||
|
framework is not in use in order to minimise the need to use
|
||||||
|
ifdefs.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<sect1 id="consumer-enable">
|
||||||
|
<title>Enabling and disabling</title>
|
||||||
|
<para>
|
||||||
|
The regulator API provides reference counted enabling and
|
||||||
|
disabling of regulators. Consumer devices use the <function><link
|
||||||
|
linkend='API-regulator-enable'>regulator_enable</link></function>
|
||||||
|
and <function><link
|
||||||
|
linkend='API-regulator-disable'>regulator_disable</link>
|
||||||
|
</function> functions to enable and disable regulators. Calls
|
||||||
|
to the two functions must be balanced.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Note that since multiple consumers may be using a regulator and
|
||||||
|
machine constraints may not allow the regulator to be disabled
|
||||||
|
there is no guarantee that calling
|
||||||
|
<function>regulator_disable</function> will actually cause the
|
||||||
|
supply provided by the regulator to be disabled. Consumer
|
||||||
|
drivers should assume that the regulator may be enabled at all
|
||||||
|
times.
|
||||||
|
</para>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
<sect1 id="consumer-config">
|
||||||
|
<title>Configuration</title>
|
||||||
|
<para>
|
||||||
|
Some consumer devices may need to be able to dynamically
|
||||||
|
configure their supplies. For example, MMC drivers may need to
|
||||||
|
select the correct operating voltage for their cards. This may
|
||||||
|
be done while the regulator is enabled or disabled.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
The <function><link
|
||||||
|
linkend='API-regulator-set-voltage'>regulator_set_voltage</link>
|
||||||
|
</function> and <function><link
|
||||||
|
linkend='API-regulator-set-current-limit'
|
||||||
|
>regulator_set_current_limit</link>
|
||||||
|
</function> functions provide the primary interface for this.
|
||||||
|
Both take ranges of voltages and currents, supporting drivers
|
||||||
|
that do not require a specific value (eg, CPU frequency scaling
|
||||||
|
normally permits the CPU to use a wider range of supply
|
||||||
|
voltages at lower frequencies but does not require that the
|
||||||
|
supply voltage be lowered). Where an exact value is required
|
||||||
|
both minimum and maximum values should be identical.
|
||||||
|
</para>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
<sect1 id="consumer-callback">
|
||||||
|
<title>Callbacks</title>
|
||||||
|
<para>
|
||||||
|
Callbacks may also be <link
|
||||||
|
linkend='API-regulator-register-notifier'>registered</link>
|
||||||
|
for events such as regulation failures.
|
||||||
|
</para>
|
||||||
|
</sect1>
|
||||||
|
</chapter>
|
||||||
|
|
||||||
|
<chapter id="driver">
|
||||||
|
<title>Regulator driver interface</title>
|
||||||
|
<para>
|
||||||
|
Drivers for regulator chips <link
|
||||||
|
linkend='API-regulator-register'>register</link> the regulators
|
||||||
|
with the regulator core, providing operations structures to the
|
||||||
|
core. A <link
|
||||||
|
linkend='API-regulator-notifier-call-chain'>notifier</link> interface
|
||||||
|
allows error conditions to be reported to the core.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Registration should be triggered by explicit setup done by the
|
||||||
|
platform, supplying a <link
|
||||||
|
linkend='API-struct-regulator-init-data'>struct
|
||||||
|
regulator_init_data</link> for the regulator containing
|
||||||
|
<link linkend='machine-constraint'>constraint</link> and
|
||||||
|
<link linkend='machine-supply'>supply</link> information.
|
||||||
|
</para>
|
||||||
|
</chapter>
|
||||||
|
|
||||||
|
<chapter id="machine">
|
||||||
|
<title>Machine interface</title>
|
||||||
|
<para>
|
||||||
|
This interface provides a way to define how regulators are
|
||||||
|
connected to consumers on a given system and what the valid
|
||||||
|
operating parameters are for the system.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<sect1 id="machine-supply">
|
||||||
|
<title>Supplies</title>
|
||||||
|
<para>
|
||||||
|
Regulator supplies are specified using <link
|
||||||
|
linkend='API-struct-regulator-consumer-supply'>struct
|
||||||
|
regulator_consumer_supply</link>. This is done at
|
||||||
|
<link linkend='driver'>driver registration
|
||||||
|
time</link> as part of the machine constraints.
|
||||||
|
</para>
|
||||||
|
</sect1>
|
||||||
|
|
||||||
|
<sect1 id="machine-constraint">
|
||||||
|
<title>Constraints</title>
|
||||||
|
<para>
|
||||||
|
As well as definining the connections the machine interface
|
||||||
|
also provides constraints definining the operations that
|
||||||
|
clients are allowed to perform and the parameters that may be
|
||||||
|
set. This is required since generally regulator devices will
|
||||||
|
offer more flexibility than it is safe to use on a given
|
||||||
|
system, for example supporting higher supply voltages than the
|
||||||
|
consumers are rated for.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
This is done at <link linkend='driver'>driver
|
||||||
|
registration time</link> by providing a <link
|
||||||
|
linkend='API-struct-regulation-constraints'>struct
|
||||||
|
regulation_constraints</link>.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
The constraints may also specify an initial configuration for the
|
||||||
|
regulator in the constraints, which is particularly useful for
|
||||||
|
use with static consumers.
|
||||||
|
</para>
|
||||||
|
</sect1>
|
||||||
|
</chapter>
|
||||||
|
|
||||||
|
<chapter id="api">
|
||||||
|
<title>API reference</title>
|
||||||
|
<para>
|
||||||
|
Due to limitations of the kernel documentation framework and the
|
||||||
|
existing layout of the source code the entire regulator API is
|
||||||
|
documented here.
|
||||||
|
</para>
|
||||||
|
!Iinclude/linux/regulator/consumer.h
|
||||||
|
!Iinclude/linux/regulator/machine.h
|
||||||
|
!Iinclude/linux/regulator/driver.h
|
||||||
|
!Edrivers/regulator/core.c
|
||||||
|
</chapter>
|
||||||
|
</book>
|
|
@ -41,6 +41,12 @@ GPL version 2.
|
||||||
</abstract>
|
</abstract>
|
||||||
|
|
||||||
<revhistory>
|
<revhistory>
|
||||||
|
<revision>
|
||||||
|
<revnumber>0.6</revnumber>
|
||||||
|
<date>2008-12-05</date>
|
||||||
|
<authorinitials>hjk</authorinitials>
|
||||||
|
<revremark>Added description of portio sysfs attributes.</revremark>
|
||||||
|
</revision>
|
||||||
<revision>
|
<revision>
|
||||||
<revnumber>0.5</revnumber>
|
<revnumber>0.5</revnumber>
|
||||||
<date>2008-05-22</date>
|
<date>2008-05-22</date>
|
||||||
|
@ -318,6 +324,54 @@ interested in translating it, please email me
|
||||||
offset = N * getpagesize();
|
offset = N * getpagesize();
|
||||||
</programlisting>
|
</programlisting>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Sometimes there is hardware with memory-like regions that can not be
|
||||||
|
mapped with the technique described here, but there are still ways to
|
||||||
|
access them from userspace. The most common example are x86 ioports.
|
||||||
|
On x86 systems, userspace can access these ioports using
|
||||||
|
<function>ioperm()</function>, <function>iopl()</function>,
|
||||||
|
<function>inb()</function>, <function>outb()</function>, and similar
|
||||||
|
functions.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Since these ioport regions can not be mapped, they will not appear under
|
||||||
|
<filename>/sys/class/uio/uioX/maps/</filename> like the normal memory
|
||||||
|
described above. Without information about the port regions a hardware
|
||||||
|
has to offer, it becomes difficult for the userspace part of the
|
||||||
|
driver to find out which ports belong to which UIO device.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
To address this situation, the new directory
|
||||||
|
<filename>/sys/class/uio/uioX/portio/</filename> was added. It only
|
||||||
|
exists if the driver wants to pass information about one or more port
|
||||||
|
regions to userspace. If that is the case, subdirectories named
|
||||||
|
<filename>port0</filename>, <filename>port1</filename>, and so on,
|
||||||
|
will appear underneath
|
||||||
|
<filename>/sys/class/uio/uioX/portio/</filename>.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Each <filename>portX/</filename> directory contains three read-only
|
||||||
|
files that show start, size, and type of the port region:
|
||||||
|
</para>
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<filename>start</filename>: The first port of this region.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<filename>size</filename>: The number of ports in this region.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<filename>porttype</filename>: A string describing the type of port.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
</chapter>
|
</chapter>
|
||||||
|
|
||||||
|
@ -339,12 +393,12 @@ offset = N * getpagesize();
|
||||||
|
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem><para>
|
<listitem><para>
|
||||||
<varname>char *name</varname>: Required. The name of your driver as
|
<varname>const char *name</varname>: Required. The name of your driver as
|
||||||
it will appear in sysfs. I recommend using the name of your module for this.
|
it will appear in sysfs. I recommend using the name of your module for this.
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
|
|
||||||
<listitem><para>
|
<listitem><para>
|
||||||
<varname>char *version</varname>: Required. This string appears in
|
<varname>const char *version</varname>: Required. This string appears in
|
||||||
<filename>/sys/class/uio/uioX/version</filename>.
|
<filename>/sys/class/uio/uioX/version</filename>.
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
|
|
||||||
|
@ -355,6 +409,13 @@ mapping you need to fill one of the <varname>uio_mem</varname> structures.
|
||||||
See the description below for details.
|
See the description below for details.
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
|
|
||||||
|
<listitem><para>
|
||||||
|
<varname>struct uio_port port[ MAX_UIO_PORTS_REGIONS ]</varname>: Required
|
||||||
|
if you want to pass information about ioports to userspace. For each port
|
||||||
|
region you need to fill one of the <varname>uio_port</varname> structures.
|
||||||
|
See the description below for details.
|
||||||
|
</para></listitem>
|
||||||
|
|
||||||
<listitem><para>
|
<listitem><para>
|
||||||
<varname>long irq</varname>: Required. If your hardware generates an
|
<varname>long irq</varname>: Required. If your hardware generates an
|
||||||
interrupt, it's your modules task to determine the irq number during
|
interrupt, it's your modules task to determine the irq number during
|
||||||
|
@ -448,6 +509,42 @@ Please do not touch the <varname>kobj</varname> element of
|
||||||
<varname>struct uio_mem</varname>! It is used by the UIO framework
|
<varname>struct uio_mem</varname>! It is used by the UIO framework
|
||||||
to set up sysfs files for this mapping. Simply leave it alone.
|
to set up sysfs files for this mapping. Simply leave it alone.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Sometimes, your device can have one or more port regions which can not be
|
||||||
|
mapped to userspace. But if there are other possibilities for userspace to
|
||||||
|
access these ports, it makes sense to make information about the ports
|
||||||
|
available in sysfs. For each region, you have to set up a
|
||||||
|
<varname>struct uio_port</varname> in the <varname>port[]</varname> array.
|
||||||
|
Here's a description of the fields of <varname>struct uio_port</varname>:
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem><para>
|
||||||
|
<varname>char *porttype</varname>: Required. Set this to one of the predefined
|
||||||
|
constants. Use <varname>UIO_PORT_X86</varname> for the ioports found in x86
|
||||||
|
architectures.
|
||||||
|
</para></listitem>
|
||||||
|
|
||||||
|
<listitem><para>
|
||||||
|
<varname>unsigned long start</varname>: Required if the port region is used.
|
||||||
|
Fill in the number of the first port of this region.
|
||||||
|
</para></listitem>
|
||||||
|
|
||||||
|
<listitem><para>
|
||||||
|
<varname>unsigned long size</varname>: Fill in the number of ports in this
|
||||||
|
region. If <varname>size</varname> is zero, the region is considered unused.
|
||||||
|
Note that you <emphasis>must</emphasis> initialize <varname>size</varname>
|
||||||
|
with zero for all unused regions.
|
||||||
|
</para></listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Please do not touch the <varname>portio</varname> element of
|
||||||
|
<varname>struct uio_port</varname>! It is used internally by the UIO
|
||||||
|
framework to set up sysfs files for this region. Simply leave it alone.
|
||||||
|
</para>
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
<sect1 id="adding_irq_handler">
|
<sect1 id="adding_irq_handler">
|
||||||
|
|
|
@ -1,99 +0,0 @@
|
||||||
<?xml version="1.0" encoding="UTF-8"?>
|
|
||||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
|
||||||
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
|
||||||
|
|
||||||
<book id="WANGuide">
|
|
||||||
<bookinfo>
|
|
||||||
<title>Synchronous PPP and Cisco HDLC Programming Guide</title>
|
|
||||||
|
|
||||||
<authorgroup>
|
|
||||||
<author>
|
|
||||||
<firstname>Alan</firstname>
|
|
||||||
<surname>Cox</surname>
|
|
||||||
<affiliation>
|
|
||||||
<address>
|
|
||||||
<email>alan@lxorguk.ukuu.org.uk</email>
|
|
||||||
</address>
|
|
||||||
</affiliation>
|
|
||||||
</author>
|
|
||||||
</authorgroup>
|
|
||||||
|
|
||||||
<copyright>
|
|
||||||
<year>2000</year>
|
|
||||||
<holder>Alan Cox</holder>
|
|
||||||
</copyright>
|
|
||||||
|
|
||||||
<legalnotice>
|
|
||||||
<para>
|
|
||||||
This documentation is free software; you can redistribute
|
|
||||||
it and/or modify it under the terms of the GNU General Public
|
|
||||||
License as published by the Free Software Foundation; either
|
|
||||||
version 2 of the License, or (at your option) any later
|
|
||||||
version.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
This program is distributed in the hope that it will be
|
|
||||||
useful, but WITHOUT ANY WARRANTY; without even the implied
|
|
||||||
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
|
||||||
See the GNU General Public License for more details.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
You should have received a copy of the GNU General Public
|
|
||||||
License along with this program; if not, write to the Free
|
|
||||||
Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
|
|
||||||
MA 02111-1307 USA
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>
|
|
||||||
For more details see the file COPYING in the source
|
|
||||||
distribution of Linux.
|
|
||||||
</para>
|
|
||||||
</legalnotice>
|
|
||||||
</bookinfo>
|
|
||||||
|
|
||||||
<toc></toc>
|
|
||||||
|
|
||||||
<chapter id="intro">
|
|
||||||
<title>Introduction</title>
|
|
||||||
<para>
|
|
||||||
The syncppp drivers in Linux provide a fairly complete
|
|
||||||
implementation of Cisco HDLC and a minimal implementation of
|
|
||||||
PPP. The longer term goal is to switch the PPP layer to the
|
|
||||||
generic PPP interface that is new in Linux 2.3.x. The API should
|
|
||||||
remain unchanged when this is done, but support will then be
|
|
||||||
available for IPX, compression and other PPP features
|
|
||||||
</para>
|
|
||||||
</chapter>
|
|
||||||
<chapter id="bugs">
|
|
||||||
<title>Known Bugs And Assumptions</title>
|
|
||||||
<para>
|
|
||||||
<variablelist>
|
|
||||||
<varlistentry><term>PPP is minimal</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
The current PPP implementation is very basic, although sufficient
|
|
||||||
for most wan usages.
|
|
||||||
</para>
|
|
||||||
</listitem></varlistentry>
|
|
||||||
|
|
||||||
<varlistentry><term>Cisco HDLC Quirks</term>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
Currently we do not end all packets with the correct Cisco multicast
|
|
||||||
or unicast flags. Nothing appears to mind too much but this should
|
|
||||||
be corrected.
|
|
||||||
</para>
|
|
||||||
</listitem></varlistentry>
|
|
||||||
</variablelist>
|
|
||||||
|
|
||||||
</para>
|
|
||||||
</chapter>
|
|
||||||
|
|
||||||
<chapter id="pubfunctions">
|
|
||||||
<title>Public Functions Provided</title>
|
|
||||||
!Edrivers/net/wan/syncppp.c
|
|
||||||
</chapter>
|
|
||||||
|
|
||||||
</book>
|
|
|
@ -294,7 +294,8 @@ NOTE: pci_enable_device() can fail! Check the return value.
|
||||||
|
|
||||||
pci_set_master() will enable DMA by setting the bus master bit
|
pci_set_master() will enable DMA by setting the bus master bit
|
||||||
in the PCI_COMMAND register. It also fixes the latency timer value if
|
in the PCI_COMMAND register. It also fixes the latency timer value if
|
||||||
it's set to something bogus by the BIOS.
|
it's set to something bogus by the BIOS. pci_clear_master() will
|
||||||
|
disable DMA by clearing the bus master bit.
|
||||||
|
|
||||||
If the PCI device can use the PCI Memory-Write-Invalidate transaction,
|
If the PCI device can use the PCI Memory-Write-Invalidate transaction,
|
||||||
call pci_set_mwi(). This enables the PCI_COMMAND bit for Mem-Wr-Inval
|
call pci_set_mwi(). This enables the PCI_COMMAND bit for Mem-Wr-Inval
|
||||||
|
|
|
@ -12,10 +12,14 @@ rcuref.txt
|
||||||
- Reference-count design for elements of lists/arrays protected by RCU
|
- Reference-count design for elements of lists/arrays protected by RCU
|
||||||
rcu.txt
|
rcu.txt
|
||||||
- RCU Concepts
|
- RCU Concepts
|
||||||
|
rcubarrier.txt
|
||||||
|
- Unloading modules that use RCU callbacks
|
||||||
RTFP.txt
|
RTFP.txt
|
||||||
- List of RCU papers (bibliography) going back to 1980.
|
- List of RCU papers (bibliography) going back to 1980.
|
||||||
torture.txt
|
torture.txt
|
||||||
- RCU Torture Test Operation (CONFIG_RCU_TORTURE_TEST)
|
- RCU Torture Test Operation (CONFIG_RCU_TORTURE_TEST)
|
||||||
|
trace.txt
|
||||||
|
- CONFIG_RCU_TRACE debugfs files and formats
|
||||||
UP.txt
|
UP.txt
|
||||||
- RCU on Uniprocessor Systems
|
- RCU on Uniprocessor Systems
|
||||||
whatisRCU.txt
|
whatisRCU.txt
|
||||||
|
|
|
@ -0,0 +1,304 @@
|
||||||
|
RCU and Unloadable Modules
|
||||||
|
|
||||||
|
[Originally published in LWN Jan. 14, 2007: http://lwn.net/Articles/217484/]
|
||||||
|
|
||||||
|
RCU (read-copy update) is a synchronization mechanism that can be thought
|
||||||
|
of as a replacement for read-writer locking (among other things), but with
|
||||||
|
very low-overhead readers that are immune to deadlock, priority inversion,
|
||||||
|
and unbounded latency. RCU read-side critical sections are delimited
|
||||||
|
by rcu_read_lock() and rcu_read_unlock(), which, in non-CONFIG_PREEMPT
|
||||||
|
kernels, generate no code whatsoever.
|
||||||
|
|
||||||
|
This means that RCU writers are unaware of the presence of concurrent
|
||||||
|
readers, so that RCU updates to shared data must be undertaken quite
|
||||||
|
carefully, leaving an old version of the data structure in place until all
|
||||||
|
pre-existing readers have finished. These old versions are needed because
|
||||||
|
such readers might hold a reference to them. RCU updates can therefore be
|
||||||
|
rather expensive, and RCU is thus best suited for read-mostly situations.
|
||||||
|
|
||||||
|
How can an RCU writer possibly determine when all readers are finished,
|
||||||
|
given that readers might well leave absolutely no trace of their
|
||||||
|
presence? There is a synchronize_rcu() primitive that blocks until all
|
||||||
|
pre-existing readers have completed. An updater wishing to delete an
|
||||||
|
element p from a linked list might do the following, while holding an
|
||||||
|
appropriate lock, of course:
|
||||||
|
|
||||||
|
list_del_rcu(p);
|
||||||
|
synchronize_rcu();
|
||||||
|
kfree(p);
|
||||||
|
|
||||||
|
But the above code cannot be used in IRQ context -- the call_rcu()
|
||||||
|
primitive must be used instead. This primitive takes a pointer to an
|
||||||
|
rcu_head struct placed within the RCU-protected data structure and
|
||||||
|
another pointer to a function that may be invoked later to free that
|
||||||
|
structure. Code to delete an element p from the linked list from IRQ
|
||||||
|
context might then be as follows:
|
||||||
|
|
||||||
|
list_del_rcu(p);
|
||||||
|
call_rcu(&p->rcu, p_callback);
|
||||||
|
|
||||||
|
Since call_rcu() never blocks, this code can safely be used from within
|
||||||
|
IRQ context. The function p_callback() might be defined as follows:
|
||||||
|
|
||||||
|
static void p_callback(struct rcu_head *rp)
|
||||||
|
{
|
||||||
|
struct pstruct *p = container_of(rp, struct pstruct, rcu);
|
||||||
|
|
||||||
|
kfree(p);
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
Unloading Modules That Use call_rcu()
|
||||||
|
|
||||||
|
But what if p_callback is defined in an unloadable module?
|
||||||
|
|
||||||
|
If we unload the module while some RCU callbacks are pending,
|
||||||
|
the CPUs executing these callbacks are going to be severely
|
||||||
|
disappointed when they are later invoked, as fancifully depicted at
|
||||||
|
http://lwn.net/images/ns/kernel/rcu-drop.jpg.
|
||||||
|
|
||||||
|
We could try placing a synchronize_rcu() in the module-exit code path,
|
||||||
|
but this is not sufficient. Although synchronize_rcu() does wait for a
|
||||||
|
grace period to elapse, it does not wait for the callbacks to complete.
|
||||||
|
|
||||||
|
One might be tempted to try several back-to-back synchronize_rcu()
|
||||||
|
calls, but this is still not guaranteed to work. If there is a very
|
||||||
|
heavy RCU-callback load, then some of the callbacks might be deferred
|
||||||
|
in order to allow other processing to proceed. Such deferral is required
|
||||||
|
in realtime kernels in order to avoid excessive scheduling latencies.
|
||||||
|
|
||||||
|
|
||||||
|
rcu_barrier()
|
||||||
|
|
||||||
|
We instead need the rcu_barrier() primitive. This primitive is similar
|
||||||
|
to synchronize_rcu(), but instead of waiting solely for a grace
|
||||||
|
period to elapse, it also waits for all outstanding RCU callbacks to
|
||||||
|
complete. Pseudo-code using rcu_barrier() is as follows:
|
||||||
|
|
||||||
|
1. Prevent any new RCU callbacks from being posted.
|
||||||
|
2. Execute rcu_barrier().
|
||||||
|
3. Allow the module to be unloaded.
|
||||||
|
|
||||||
|
Quick Quiz #1: Why is there no srcu_barrier()?
|
||||||
|
|
||||||
|
The rcutorture module makes use of rcu_barrier in its exit function
|
||||||
|
as follows:
|
||||||
|
|
||||||
|
1 static void
|
||||||
|
2 rcu_torture_cleanup(void)
|
||||||
|
3 {
|
||||||
|
4 int i;
|
||||||
|
5
|
||||||
|
6 fullstop = 1;
|
||||||
|
7 if (shuffler_task != NULL) {
|
||||||
|
8 VERBOSE_PRINTK_STRING("Stopping rcu_torture_shuffle task");
|
||||||
|
9 kthread_stop(shuffler_task);
|
||||||
|
10 }
|
||||||
|
11 shuffler_task = NULL;
|
||||||
|
12
|
||||||
|
13 if (writer_task != NULL) {
|
||||||
|
14 VERBOSE_PRINTK_STRING("Stopping rcu_torture_writer task");
|
||||||
|
15 kthread_stop(writer_task);
|
||||||
|
16 }
|
||||||
|
17 writer_task = NULL;
|
||||||
|
18
|
||||||
|
19 if (reader_tasks != NULL) {
|
||||||
|
20 for (i = 0; i < nrealreaders; i++) {
|
||||||
|
21 if (reader_tasks[i] != NULL) {
|
||||||
|
22 VERBOSE_PRINTK_STRING(
|
||||||
|
23 "Stopping rcu_torture_reader task");
|
||||||
|
24 kthread_stop(reader_tasks[i]);
|
||||||
|
25 }
|
||||||
|
26 reader_tasks[i] = NULL;
|
||||||
|
27 }
|
||||||
|
28 kfree(reader_tasks);
|
||||||
|
29 reader_tasks = NULL;
|
||||||
|
30 }
|
||||||
|
31 rcu_torture_current = NULL;
|
||||||
|
32
|
||||||
|
33 if (fakewriter_tasks != NULL) {
|
||||||
|
34 for (i = 0; i < nfakewriters; i++) {
|
||||||
|
35 if (fakewriter_tasks[i] != NULL) {
|
||||||
|
36 VERBOSE_PRINTK_STRING(
|
||||||
|
37 "Stopping rcu_torture_fakewriter task");
|
||||||
|
38 kthread_stop(fakewriter_tasks[i]);
|
||||||
|
39 }
|
||||||
|
40 fakewriter_tasks[i] = NULL;
|
||||||
|
41 }
|
||||||
|
42 kfree(fakewriter_tasks);
|
||||||
|
43 fakewriter_tasks = NULL;
|
||||||
|
44 }
|
||||||
|
45
|
||||||
|
46 if (stats_task != NULL) {
|
||||||
|
47 VERBOSE_PRINTK_STRING("Stopping rcu_torture_stats task");
|
||||||
|
48 kthread_stop(stats_task);
|
||||||
|
49 }
|
||||||
|
50 stats_task = NULL;
|
||||||
|
51
|
||||||
|
52 /* Wait for all RCU callbacks to fire. */
|
||||||
|
53 rcu_barrier();
|
||||||
|
54
|
||||||
|
55 rcu_torture_stats_print(); /* -After- the stats thread is stopped! */
|
||||||
|
56
|
||||||
|
57 if (cur_ops->cleanup != NULL)
|
||||||
|
58 cur_ops->cleanup();
|
||||||
|
59 if (atomic_read(&n_rcu_torture_error))
|
||||||
|
60 rcu_torture_print_module_parms("End of test: FAILURE");
|
||||||
|
61 else
|
||||||
|
62 rcu_torture_print_module_parms("End of test: SUCCESS");
|
||||||
|
63 }
|
||||||
|
|
||||||
|
Line 6 sets a global variable that prevents any RCU callbacks from
|
||||||
|
re-posting themselves. This will not be necessary in most cases, since
|
||||||
|
RCU callbacks rarely include calls to call_rcu(). However, the rcutorture
|
||||||
|
module is an exception to this rule, and therefore needs to set this
|
||||||
|
global variable.
|
||||||
|
|
||||||
|
Lines 7-50 stop all the kernel tasks associated with the rcutorture
|
||||||
|
module. Therefore, once execution reaches line 53, no more rcutorture
|
||||||
|
RCU callbacks will be posted. The rcu_barrier() call on line 53 waits
|
||||||
|
for any pre-existing callbacks to complete.
|
||||||
|
|
||||||
|
Then lines 55-62 print status and do operation-specific cleanup, and
|
||||||
|
then return, permitting the module-unload operation to be completed.
|
||||||
|
|
||||||
|
Quick Quiz #2: Is there any other situation where rcu_barrier() might
|
||||||
|
be required?
|
||||||
|
|
||||||
|
Your module might have additional complications. For example, if your
|
||||||
|
module invokes call_rcu() from timers, you will need to first cancel all
|
||||||
|
the timers, and only then invoke rcu_barrier() to wait for any remaining
|
||||||
|
RCU callbacks to complete.
|
||||||
|
|
||||||
|
|
||||||
|
Implementing rcu_barrier()
|
||||||
|
|
||||||
|
Dipankar Sarma's implementation of rcu_barrier() makes use of the fact
|
||||||
|
that RCU callbacks are never reordered once queued on one of the per-CPU
|
||||||
|
queues. His implementation queues an RCU callback on each of the per-CPU
|
||||||
|
callback queues, and then waits until they have all started executing, at
|
||||||
|
which point, all earlier RCU callbacks are guaranteed to have completed.
|
||||||
|
|
||||||
|
The original code for rcu_barrier() was as follows:
|
||||||
|
|
||||||
|
1 void rcu_barrier(void)
|
||||||
|
2 {
|
||||||
|
3 BUG_ON(in_interrupt());
|
||||||
|
4 /* Take cpucontrol mutex to protect against CPU hotplug */
|
||||||
|
5 mutex_lock(&rcu_barrier_mutex);
|
||||||
|
6 init_completion(&rcu_barrier_completion);
|
||||||
|
7 atomic_set(&rcu_barrier_cpu_count, 0);
|
||||||
|
8 on_each_cpu(rcu_barrier_func, NULL, 0, 1);
|
||||||
|
9 wait_for_completion(&rcu_barrier_completion);
|
||||||
|
10 mutex_unlock(&rcu_barrier_mutex);
|
||||||
|
11 }
|
||||||
|
|
||||||
|
Line 3 verifies that the caller is in process context, and lines 5 and 10
|
||||||
|
use rcu_barrier_mutex to ensure that only one rcu_barrier() is using the
|
||||||
|
global completion and counters at a time, which are initialized on lines
|
||||||
|
6 and 7. Line 8 causes each CPU to invoke rcu_barrier_func(), which is
|
||||||
|
shown below. Note that the final "1" in on_each_cpu()'s argument list
|
||||||
|
ensures that all the calls to rcu_barrier_func() will have completed
|
||||||
|
before on_each_cpu() returns. Line 9 then waits for the completion.
|
||||||
|
|
||||||
|
This code was rewritten in 2008 to support rcu_barrier_bh() and
|
||||||
|
rcu_barrier_sched() in addition to the original rcu_barrier().
|
||||||
|
|
||||||
|
The rcu_barrier_func() runs on each CPU, where it invokes call_rcu()
|
||||||
|
to post an RCU callback, as follows:
|
||||||
|
|
||||||
|
1 static void rcu_barrier_func(void *notused)
|
||||||
|
2 {
|
||||||
|
3 int cpu = smp_processor_id();
|
||||||
|
4 struct rcu_data *rdp = &per_cpu(rcu_data, cpu);
|
||||||
|
5 struct rcu_head *head;
|
||||||
|
6
|
||||||
|
7 head = &rdp->barrier;
|
||||||
|
8 atomic_inc(&rcu_barrier_cpu_count);
|
||||||
|
9 call_rcu(head, rcu_barrier_callback);
|
||||||
|
10 }
|
||||||
|
|
||||||
|
Lines 3 and 4 locate RCU's internal per-CPU rcu_data structure,
|
||||||
|
which contains the struct rcu_head that needed for the later call to
|
||||||
|
call_rcu(). Line 7 picks up a pointer to this struct rcu_head, and line
|
||||||
|
8 increments a global counter. This counter will later be decremented
|
||||||
|
by the callback. Line 9 then registers the rcu_barrier_callback() on
|
||||||
|
the current CPU's queue.
|
||||||
|
|
||||||
|
The rcu_barrier_callback() function simply atomically decrements the
|
||||||
|
rcu_barrier_cpu_count variable and finalizes the completion when it
|
||||||
|
reaches zero, as follows:
|
||||||
|
|
||||||
|
1 static void rcu_barrier_callback(struct rcu_head *notused)
|
||||||
|
2 {
|
||||||
|
3 if (atomic_dec_and_test(&rcu_barrier_cpu_count))
|
||||||
|
4 complete(&rcu_barrier_completion);
|
||||||
|
5 }
|
||||||
|
|
||||||
|
Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes
|
||||||
|
immediately (thus incrementing rcu_barrier_cpu_count to the
|
||||||
|
value one), but the other CPU's rcu_barrier_func() invocations
|
||||||
|
are delayed for a full grace period? Couldn't this result in
|
||||||
|
rcu_barrier() returning prematurely?
|
||||||
|
|
||||||
|
|
||||||
|
rcu_barrier() Summary
|
||||||
|
|
||||||
|
The rcu_barrier() primitive has seen relatively little use, since most
|
||||||
|
code using RCU is in the core kernel rather than in modules. However, if
|
||||||
|
you are using RCU from an unloadable module, you need to use rcu_barrier()
|
||||||
|
so that your module may be safely unloaded.
|
||||||
|
|
||||||
|
|
||||||
|
Answers to Quick Quizzes
|
||||||
|
|
||||||
|
Quick Quiz #1: Why is there no srcu_barrier()?
|
||||||
|
|
||||||
|
Answer: Since there is no call_srcu(), there can be no outstanding SRCU
|
||||||
|
callbacks. Therefore, there is no need to wait for them.
|
||||||
|
|
||||||
|
Quick Quiz #2: Is there any other situation where rcu_barrier() might
|
||||||
|
be required?
|
||||||
|
|
||||||
|
Answer: Interestingly enough, rcu_barrier() was not originally
|
||||||
|
implemented for module unloading. Nikita Danilov was using
|
||||||
|
RCU in a filesystem, which resulted in a similar situation at
|
||||||
|
filesystem-unmount time. Dipankar Sarma coded up rcu_barrier()
|
||||||
|
in response, so that Nikita could invoke it during the
|
||||||
|
filesystem-unmount process.
|
||||||
|
|
||||||
|
Much later, yours truly hit the RCU module-unload problem when
|
||||||
|
implementing rcutorture, and found that rcu_barrier() solves
|
||||||
|
this problem as well.
|
||||||
|
|
||||||
|
Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes
|
||||||
|
immediately (thus incrementing rcu_barrier_cpu_count to the
|
||||||
|
value one), but the other CPU's rcu_barrier_func() invocations
|
||||||
|
are delayed for a full grace period? Couldn't this result in
|
||||||
|
rcu_barrier() returning prematurely?
|
||||||
|
|
||||||
|
Answer: This cannot happen. The reason is that on_each_cpu() has its last
|
||||||
|
argument, the wait flag, set to "1". This flag is passed through
|
||||||
|
to smp_call_function() and further to smp_call_function_on_cpu(),
|
||||||
|
causing this latter to spin until the cross-CPU invocation of
|
||||||
|
rcu_barrier_func() has completed. This by itself would prevent
|
||||||
|
a grace period from completing on non-CONFIG_PREEMPT kernels,
|
||||||
|
since each CPU must undergo a context switch (or other quiescent
|
||||||
|
state) before the grace period can complete. However, this is
|
||||||
|
of no use in CONFIG_PREEMPT kernels.
|
||||||
|
|
||||||
|
Therefore, on_each_cpu() disables preemption across its call
|
||||||
|
to smp_call_function() and also across the local call to
|
||||||
|
rcu_barrier_func(). This prevents the local CPU from context
|
||||||
|
switching, again preventing grace periods from completing. This
|
||||||
|
means that all CPUs have executed rcu_barrier_func() before
|
||||||
|
the first rcu_barrier_callback() can possibly execute, in turn
|
||||||
|
preventing rcu_barrier_cpu_count from prematurely reaching zero.
|
||||||
|
|
||||||
|
Currently, -rt implementations of RCU keep but a single global
|
||||||
|
queue for RCU callbacks, and thus do not suffer from this
|
||||||
|
problem. However, when the -rt RCU eventually does have per-CPU
|
||||||
|
callback queues, things will have to change. One simple change
|
||||||
|
is to add an rcu_read_lock() before line 8 of rcu_barrier()
|
||||||
|
and an rcu_read_unlock() after line 8 of this same function. If
|
||||||
|
you can think of a better change, please let me know!
|
|
@ -0,0 +1,167 @@
|
||||||
|
Using hlist_nulls to protect read-mostly linked lists and
|
||||||
|
objects using SLAB_DESTROY_BY_RCU allocations.
|
||||||
|
|
||||||
|
Please read the basics in Documentation/RCU/listRCU.txt
|
||||||
|
|
||||||
|
Using special makers (called 'nulls') is a convenient way
|
||||||
|
to solve following problem :
|
||||||
|
|
||||||
|
A typical RCU linked list managing objects which are
|
||||||
|
allocated with SLAB_DESTROY_BY_RCU kmem_cache can
|
||||||
|
use following algos :
|
||||||
|
|
||||||
|
1) Lookup algo
|
||||||
|
--------------
|
||||||
|
rcu_read_lock()
|
||||||
|
begin:
|
||||||
|
obj = lockless_lookup(key);
|
||||||
|
if (obj) {
|
||||||
|
if (!try_get_ref(obj)) // might fail for free objects
|
||||||
|
goto begin;
|
||||||
|
/*
|
||||||
|
* Because a writer could delete object, and a writer could
|
||||||
|
* reuse these object before the RCU grace period, we
|
||||||
|
* must check key after geting the reference on object
|
||||||
|
*/
|
||||||
|
if (obj->key != key) { // not the object we expected
|
||||||
|
put_ref(obj);
|
||||||
|
goto begin;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
rcu_read_unlock();
|
||||||
|
|
||||||
|
Beware that lockless_lookup(key) cannot use traditional hlist_for_each_entry_rcu()
|
||||||
|
but a version with an additional memory barrier (smp_rmb())
|
||||||
|
|
||||||
|
lockless_lookup(key)
|
||||||
|
{
|
||||||
|
struct hlist_node *node, *next;
|
||||||
|
for (pos = rcu_dereference((head)->first);
|
||||||
|
pos && ({ next = pos->next; smp_rmb(); prefetch(next); 1; }) &&
|
||||||
|
({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
|
||||||
|
pos = rcu_dereference(next))
|
||||||
|
if (obj->key == key)
|
||||||
|
return obj;
|
||||||
|
return NULL;
|
||||||
|
|
||||||
|
And note the traditional hlist_for_each_entry_rcu() misses this smp_rmb() :
|
||||||
|
|
||||||
|
struct hlist_node *node;
|
||||||
|
for (pos = rcu_dereference((head)->first);
|
||||||
|
pos && ({ prefetch(pos->next); 1; }) &&
|
||||||
|
({ tpos = hlist_entry(pos, typeof(*tpos), member); 1; });
|
||||||
|
pos = rcu_dereference(pos->next))
|
||||||
|
if (obj->key == key)
|
||||||
|
return obj;
|
||||||
|
return NULL;
|
||||||
|
}
|
||||||
|
|
||||||
|
Quoting Corey Minyard :
|
||||||
|
|
||||||
|
"If the object is moved from one list to another list in-between the
|
||||||
|
time the hash is calculated and the next field is accessed, and the
|
||||||
|
object has moved to the end of a new list, the traversal will not
|
||||||
|
complete properly on the list it should have, since the object will
|
||||||
|
be on the end of the new list and there's not a way to tell it's on a
|
||||||
|
new list and restart the list traversal. I think that this can be
|
||||||
|
solved by pre-fetching the "next" field (with proper barriers) before
|
||||||
|
checking the key."
|
||||||
|
|
||||||
|
2) Insert algo :
|
||||||
|
----------------
|
||||||
|
|
||||||
|
We need to make sure a reader cannot read the new 'obj->obj_next' value
|
||||||
|
and previous value of 'obj->key'. Or else, an item could be deleted
|
||||||
|
from a chain, and inserted into another chain. If new chain was empty
|
||||||
|
before the move, 'next' pointer is NULL, and lockless reader can
|
||||||
|
not detect it missed following items in original chain.
|
||||||
|
|
||||||
|
/*
|
||||||
|
* Please note that new inserts are done at the head of list,
|
||||||
|
* not in the middle or end.
|
||||||
|
*/
|
||||||
|
obj = kmem_cache_alloc(...);
|
||||||
|
lock_chain(); // typically a spin_lock()
|
||||||
|
obj->key = key;
|
||||||
|
atomic_inc(&obj->refcnt);
|
||||||
|
/*
|
||||||
|
* we need to make sure obj->key is updated before obj->next
|
||||||
|
*/
|
||||||
|
smp_wmb();
|
||||||
|
hlist_add_head_rcu(&obj->obj_node, list);
|
||||||
|
unlock_chain(); // typically a spin_unlock()
|
||||||
|
|
||||||
|
|
||||||
|
3) Remove algo
|
||||||
|
--------------
|
||||||
|
Nothing special here, we can use a standard RCU hlist deletion.
|
||||||
|
But thanks to SLAB_DESTROY_BY_RCU, beware a deleted object can be reused
|
||||||
|
very very fast (before the end of RCU grace period)
|
||||||
|
|
||||||
|
if (put_last_reference_on(obj) {
|
||||||
|
lock_chain(); // typically a spin_lock()
|
||||||
|
hlist_del_init_rcu(&obj->obj_node);
|
||||||
|
unlock_chain(); // typically a spin_unlock()
|
||||||
|
kmem_cache_free(cachep, obj);
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
--------------------------------------------------------------------------
|
||||||
|
With hlist_nulls we can avoid extra smp_rmb() in lockless_lookup()
|
||||||
|
and extra smp_wmb() in insert function.
|
||||||
|
|
||||||
|
For example, if we choose to store the slot number as the 'nulls'
|
||||||
|
end-of-list marker for each slot of the hash table, we can detect
|
||||||
|
a race (some writer did a delete and/or a move of an object
|
||||||
|
to another chain) checking the final 'nulls' value if
|
||||||
|
the lookup met the end of chain. If final 'nulls' value
|
||||||
|
is not the slot number, then we must restart the lookup at
|
||||||
|
the begining. If the object was moved to same chain,
|
||||||
|
then the reader doesnt care : It might eventually
|
||||||
|
scan the list again without harm.
|
||||||
|
|
||||||
|
|
||||||
|
1) lookup algo
|
||||||
|
|
||||||
|
head = &table[slot];
|
||||||
|
rcu_read_lock();
|
||||||
|
begin:
|
||||||
|
hlist_nulls_for_each_entry_rcu(obj, node, head, member) {
|
||||||
|
if (obj->key == key) {
|
||||||
|
if (!try_get_ref(obj)) // might fail for free objects
|
||||||
|
goto begin;
|
||||||
|
if (obj->key != key) { // not the object we expected
|
||||||
|
put_ref(obj);
|
||||||
|
goto begin;
|
||||||
|
}
|
||||||
|
goto out;
|
||||||
|
}
|
||||||
|
/*
|
||||||
|
* if the nulls value we got at the end of this lookup is
|
||||||
|
* not the expected one, we must restart lookup.
|
||||||
|
* We probably met an item that was moved to another chain.
|
||||||
|
*/
|
||||||
|
if (get_nulls_value(node) != slot)
|
||||||
|
goto begin;
|
||||||
|
obj = NULL;
|
||||||
|
|
||||||
|
out:
|
||||||
|
rcu_read_unlock();
|
||||||
|
|
||||||
|
2) Insert function :
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
/*
|
||||||
|
* Please note that new inserts are done at the head of list,
|
||||||
|
* not in the middle or end.
|
||||||
|
*/
|
||||||
|
obj = kmem_cache_alloc(cachep);
|
||||||
|
lock_chain(); // typically a spin_lock()
|
||||||
|
obj->key = key;
|
||||||
|
atomic_set(&obj->refcnt, 1);
|
||||||
|
/*
|
||||||
|
* insert obj in RCU way (readers might be traversing chain)
|
||||||
|
*/
|
||||||
|
hlist_nulls_add_head_rcu(&obj->obj_node, list);
|
||||||
|
unlock_chain(); // typically a spin_unlock()
|
|
@ -0,0 +1,413 @@
|
||||||
|
CONFIG_RCU_TRACE debugfs Files and Formats
|
||||||
|
|
||||||
|
|
||||||
|
The rcupreempt and rcutree 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.
|
||||||
|
Note that the rcuclassic implementation of RCU does not provide debugfs
|
||||||
|
trace output.
|
||||||
|
|
||||||
|
The following sections describe the debugfs files and formats for
|
||||||
|
preemptable RCU (rcupreempt) and hierarchical RCU (rcutree).
|
||||||
|
|
||||||
|
|
||||||
|
Preemptable RCU debugfs Files and Formats
|
||||||
|
|
||||||
|
This implementation of RCU provides three debugfs files under the
|
||||||
|
top-level directory RCU: rcu/rcuctrs (which displays the per-CPU
|
||||||
|
counters used by preemptable RCU) rcu/rcugp (which displays grace-period
|
||||||
|
counters), and rcu/rcustats (which internal counters for debugging RCU).
|
||||||
|
|
||||||
|
The output of "cat rcu/rcuctrs" looks as follows:
|
||||||
|
|
||||||
|
CPU last cur F M
|
||||||
|
0 5 -5 0 0
|
||||||
|
1 -1 0 0 0
|
||||||
|
2 0 1 0 0
|
||||||
|
3 0 1 0 0
|
||||||
|
4 0 1 0 0
|
||||||
|
5 0 1 0 0
|
||||||
|
6 0 2 0 0
|
||||||
|
7 0 -1 0 0
|
||||||
|
8 0 1 0 0
|
||||||
|
ggp = 26226, state = waitzero
|
||||||
|
|
||||||
|
The per-CPU fields are as follows:
|
||||||
|
|
||||||
|
o "CPU" gives the CPU number. Offline CPUs are not displayed.
|
||||||
|
|
||||||
|
o "last" gives the value of the counter that is being decremented
|
||||||
|
for the current grace period phase. In the example above,
|
||||||
|
the counters sum to 4, indicating that there are still four
|
||||||
|
RCU read-side critical sections still running that started
|
||||||
|
before the last counter flip.
|
||||||
|
|
||||||
|
o "cur" gives the value of the counter that is currently being
|
||||||
|
both incremented (by rcu_read_lock()) and decremented (by
|
||||||
|
rcu_read_unlock()). In the example above, the counters sum to
|
||||||
|
1, indicating that there is only one RCU read-side critical section
|
||||||
|
still running that started after the last counter flip.
|
||||||
|
|
||||||
|
o "F" indicates whether RCU is waiting for this CPU to acknowledge
|
||||||
|
a counter flip. In the above example, RCU is not waiting on any,
|
||||||
|
which is consistent with the state being "waitzero" rather than
|
||||||
|
"waitack".
|
||||||
|
|
||||||
|
o "M" indicates whether RCU is waiting for this CPU to execute a
|
||||||
|
memory barrier. In the above example, RCU is not waiting on any,
|
||||||
|
which is consistent with the state being "waitzero" rather than
|
||||||
|
"waitmb".
|
||||||
|
|
||||||
|
o "ggp" is the global grace-period counter.
|
||||||
|
|
||||||
|
o "state" is the RCU state, which can be one of the following:
|
||||||
|
|
||||||
|
o "idle": there is no grace period in progress.
|
||||||
|
|
||||||
|
o "waitack": RCU just incremented the global grace-period
|
||||||
|
counter, which has the effect of reversing the roles of
|
||||||
|
the "last" and "cur" counters above, and is waiting for
|
||||||
|
all the CPUs to acknowledge the flip. Once the flip has
|
||||||
|
been acknowledged, CPUs will no longer be incrementing
|
||||||
|
what are now the "last" counters, so that their sum will
|
||||||
|
decrease monotonically down to zero.
|
||||||
|
|
||||||
|
o "waitzero": RCU is waiting for the sum of the "last" counters
|
||||||
|
to decrease to zero.
|
||||||
|
|
||||||
|
o "waitmb": RCU is waiting for each CPU to execute a memory
|
||||||
|
barrier, which ensures that instructions from a given CPU's
|
||||||
|
last RCU read-side critical section cannot be reordered
|
||||||
|
with instructions following the memory-barrier instruction.
|
||||||
|
|
||||||
|
The output of "cat rcu/rcugp" looks as follows:
|
||||||
|
|
||||||
|
oldggp=48870 newggp=48873
|
||||||
|
|
||||||
|
Note that reading from this file provokes a synchronize_rcu(). The
|
||||||
|
"oldggp" value is that of "ggp" from rcu/rcuctrs above, taken before
|
||||||
|
executing the synchronize_rcu(), and the "newggp" value is also the
|
||||||
|
"ggp" value, but taken after the synchronize_rcu() command returns.
|
||||||
|
|
||||||
|
|
||||||
|
The output of "cat rcu/rcugp" looks as follows:
|
||||||
|
|
||||||
|
na=1337955 nl=40 wa=1337915 wl=44 da=1337871 dl=0 dr=1337871 di=1337871
|
||||||
|
1=50989 e1=6138 i1=49722 ie1=82 g1=49640 a1=315203 ae1=265563 a2=49640
|
||||||
|
z1=1401244 ze1=1351605 z2=49639 m1=5661253 me1=5611614 m2=49639
|
||||||
|
|
||||||
|
These are counters tracking internal preemptable-RCU events, however,
|
||||||
|
some of them may be useful for debugging algorithms using RCU. In
|
||||||
|
particular, the "nl", "wl", and "dl" values track the number of RCU
|
||||||
|
callbacks in various states. The fields are as follows:
|
||||||
|
|
||||||
|
o "na" is the total number of RCU callbacks that have been enqueued
|
||||||
|
since boot.
|
||||||
|
|
||||||
|
o "nl" is the number of RCU callbacks waiting for the previous
|
||||||
|
grace period to end so that they can start waiting on the next
|
||||||
|
grace period.
|
||||||
|
|
||||||
|
o "wa" is the total number of RCU callbacks that have started waiting
|
||||||
|
for a grace period since boot. "na" should be roughly equal to
|
||||||
|
"nl" plus "wa".
|
||||||
|
|
||||||
|
o "wl" is the number of RCU callbacks currently waiting for their
|
||||||
|
grace period to end.
|
||||||
|
|
||||||
|
o "da" is the total number of RCU callbacks whose grace periods
|
||||||
|
have completed since boot. "wa" should be roughly equal to
|
||||||
|
"wl" plus "da".
|
||||||
|
|
||||||
|
o "dr" is the total number of RCU callbacks that have been removed
|
||||||
|
from the list of callbacks ready to invoke. "dr" should be roughly
|
||||||
|
equal to "da".
|
||||||
|
|
||||||
|
o "di" is the total number of RCU callbacks that have been invoked
|
||||||
|
since boot. "di" should be roughly equal to "da", though some
|
||||||
|
early versions of preemptable RCU had a bug so that only the
|
||||||
|
last CPU's count of invocations was displayed, rather than the
|
||||||
|
sum of all CPU's counts.
|
||||||
|
|
||||||
|
o "1" is the number of calls to rcu_try_flip(). This should be
|
||||||
|
roughly equal to the sum of "e1", "i1", "a1", "z1", and "m1"
|
||||||
|
described below. In other words, the number of times that
|
||||||
|
the state machine is visited should be equal to the sum of the
|
||||||
|
number of times that each state is visited plus the number of
|
||||||
|
times that the state-machine lock acquisition failed.
|
||||||
|
|
||||||
|
o "e1" is the number of times that rcu_try_flip() was unable to
|
||||||
|
acquire the fliplock.
|
||||||
|
|
||||||
|
o "i1" is the number of calls to rcu_try_flip_idle().
|
||||||
|
|
||||||
|
o "ie1" is the number of times rcu_try_flip_idle() exited early
|
||||||
|
due to the calling CPU having no work for RCU.
|
||||||
|
|
||||||
|
o "g1" is the number of times that rcu_try_flip_idle() decided
|
||||||
|
to start a new grace period. "i1" should be roughly equal to
|
||||||
|
"ie1" plus "g1".
|
||||||
|
|
||||||
|
o "a1" is the number of calls to rcu_try_flip_waitack().
|
||||||
|
|
||||||
|
o "ae1" is the number of times that rcu_try_flip_waitack() found
|
||||||
|
that at least one CPU had not yet acknowledge the new grace period
|
||||||
|
(AKA "counter flip").
|
||||||
|
|
||||||
|
o "a2" is the number of time rcu_try_flip_waitack() found that
|
||||||
|
all CPUs had acknowledged. "a1" should be roughly equal to
|
||||||
|
"ae1" plus "a2". (This particular output was collected on
|
||||||
|
a 128-CPU machine, hence the smaller-than-usual fraction of
|
||||||
|
calls to rcu_try_flip_waitack() finding all CPUs having already
|
||||||
|
acknowledged.)
|
||||||
|
|
||||||
|
o "z1" is the number of calls to rcu_try_flip_waitzero().
|
||||||
|
|
||||||
|
o "ze1" is the number of times that rcu_try_flip_waitzero() found
|
||||||
|
that not all of the old RCU read-side critical sections had
|
||||||
|
completed.
|
||||||
|
|
||||||
|
o "z2" is the number of times that rcu_try_flip_waitzero() finds
|
||||||
|
the sum of the counters equal to zero, in other words, that
|
||||||
|
all of the old RCU read-side critical sections had completed.
|
||||||
|
The value of "z1" should be roughly equal to "ze1" plus
|
||||||
|
"z2".
|
||||||
|
|
||||||
|
o "m1" is the number of calls to rcu_try_flip_waitmb().
|
||||||
|
|
||||||
|
o "me1" is the number of times that rcu_try_flip_waitmb() finds
|
||||||
|
that at least one CPU has not yet executed a memory barrier.
|
||||||
|
|
||||||
|
o "m2" is the number of times that rcu_try_flip_waitmb() finds that
|
||||||
|
all CPUs have executed a memory barrier.
|
||||||
|
|
||||||
|
|
||||||
|
Hierarchical RCU debugfs Files and Formats
|
||||||
|
|
||||||
|
This implementation of RCU provides three 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).
|
||||||
|
|
||||||
|
The output of "cat rcu/rcudata" looks as follows:
|
||||||
|
|
||||||
|
rcu:
|
||||||
|
0 c=4011 g=4012 pq=1 pqc=4011 qp=0 rpfq=1 rp=3c2a dt=23301/73 dn=2 df=1882 of=0 ri=2126 ql=2 b=10
|
||||||
|
1 c=4011 g=4012 pq=1 pqc=4011 qp=0 rpfq=3 rp=39a6 dt=78073/1 dn=2 df=1402 of=0 ri=1875 ql=46 b=10
|
||||||
|
2 c=4010 g=4010 pq=1 pqc=4010 qp=0 rpfq=-5 rp=1d12 dt=16646/0 dn=2 df=3140 of=0 ri=2080 ql=0 b=10
|
||||||
|
3 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=2b50 dt=21159/1 dn=2 df=2230 of=0 ri=1923 ql=72 b=10
|
||||||
|
4 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=1644 dt=5783/1 dn=2 df=3348 of=0 ri=2805 ql=7 b=10
|
||||||
|
5 c=4012 g=4013 pq=0 pqc=4011 qp=1 rpfq=3 rp=1aac dt=5879/1 dn=2 df=3140 of=0 ri=2066 ql=10 b=10
|
||||||
|
6 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=ed8 dt=5847/1 dn=2 df=3797 of=0 ri=1266 ql=10 b=10
|
||||||
|
7 c=4012 g=4013 pq=1 pqc=4012 qp=1 rpfq=3 rp=1fa2 dt=6199/1 dn=2 df=2795 of=0 ri=2162 ql=28 b=10
|
||||||
|
rcu_bh:
|
||||||
|
0 c=-268 g=-268 pq=1 pqc=-268 qp=0 rpfq=-145 rp=21d6 dt=23301/73 dn=2 df=0 of=0 ri=0 ql=0 b=10
|
||||||
|
1 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-170 rp=20ce dt=78073/1 dn=2 df=26 of=0 ri=5 ql=0 b=10
|
||||||
|
2 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-83 rp=fbd dt=16646/0 dn=2 df=28 of=0 ri=4 ql=0 b=10
|
||||||
|
3 c=-268 g=-268 pq=1 pqc=-268 qp=0 rpfq=-105 rp=178c dt=21159/1 dn=2 df=28 of=0 ri=2 ql=0 b=10
|
||||||
|
4 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-30 rp=b54 dt=5783/1 dn=2 df=32 of=0 ri=0 ql=0 b=10
|
||||||
|
5 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-29 rp=df5 dt=5879/1 dn=2 df=30 of=0 ri=3 ql=0 b=10
|
||||||
|
6 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-28 rp=788 dt=5847/1 dn=2 df=32 of=0 ri=0 ql=0 b=10
|
||||||
|
7 c=-268 g=-268 pq=1 pqc=-268 qp=1 rpfq=-53 rp=1098 dt=6199/1 dn=2 df=30 of=0 ri=3 ql=0 b=10
|
||||||
|
|
||||||
|
The first section lists the rcu_data structures for rcu, the second for
|
||||||
|
rcu_bh. Each section has one line per CPU, or eight for this 8-CPU system.
|
||||||
|
The fields are as follows:
|
||||||
|
|
||||||
|
o The number at the beginning of each line is the CPU number.
|
||||||
|
CPUs numbers followed by an exclamation mark are offline,
|
||||||
|
but have been online at least once since boot. There will be
|
||||||
|
no output for CPUs that have never been online, which can be
|
||||||
|
a good thing in the surprisingly common case where NR_CPUS is
|
||||||
|
substantially larger than the number of actual CPUs.
|
||||||
|
|
||||||
|
o "c" is the count of grace periods that this CPU believes have
|
||||||
|
completed. CPUs in dynticks idle mode may lag quite a ways
|
||||||
|
behind, for example, CPU 4 under "rcu" above, which has slept
|
||||||
|
through the past 25 RCU grace periods. It is not unusual to
|
||||||
|
see CPUs lagging by thousands of grace periods.
|
||||||
|
|
||||||
|
o "g" is the count of grace periods that this CPU believes have
|
||||||
|
started. Again, CPUs in dynticks idle mode may lag behind.
|
||||||
|
If the "c" and "g" values are equal, this CPU has already
|
||||||
|
reported a quiescent state for the last RCU grace period that
|
||||||
|
it is aware of, otherwise, the CPU believes that it owes RCU a
|
||||||
|
quiescent state.
|
||||||
|
|
||||||
|
o "pq" indicates that this CPU has passed through a quiescent state
|
||||||
|
for the current grace period. It is possible for "pq" to be
|
||||||
|
"1" and "c" different than "g", which indicates that although
|
||||||
|
the CPU has passed through a quiescent state, either (1) this
|
||||||
|
CPU has not yet reported that fact, (2) some other CPU has not
|
||||||
|
yet reported for this grace period, or (3) both.
|
||||||
|
|
||||||
|
o "pqc" indicates which grace period the last-observed quiescent
|
||||||
|
state for this CPU corresponds to. This is important for handling
|
||||||
|
the race between CPU 0 reporting an extended dynticks-idle
|
||||||
|
quiescent state for CPU 1 and CPU 1 suddenly waking up and
|
||||||
|
reporting its own quiescent state. If CPU 1 was the last CPU
|
||||||
|
for the current grace period, then the CPU that loses this race
|
||||||
|
will attempt to incorrectly mark CPU 1 as having checked in for
|
||||||
|
the next grace period!
|
||||||
|
|
||||||
|
o "qp" indicates that RCU still expects a quiescent state from
|
||||||
|
this CPU.
|
||||||
|
|
||||||
|
o "rpfq" is the number of rcu_pending() calls on this CPU required
|
||||||
|
to induce this CPU to invoke force_quiescent_state().
|
||||||
|
|
||||||
|
o "rp" is low-order four hex digits of the count of how many times
|
||||||
|
rcu_pending() has been invoked on this CPU.
|
||||||
|
|
||||||
|
o "dt" is the current value of the dyntick counter that is incremented
|
||||||
|
when entering or leaving dynticks idle state, either by the
|
||||||
|
scheduler or by irq. The number after the "/" is the interrupt
|
||||||
|
nesting depth when in dyntick-idle state, or one greater than
|
||||||
|
the interrupt-nesting depth otherwise.
|
||||||
|
|
||||||
|
This field is displayed only for CONFIG_NO_HZ kernels.
|
||||||
|
|
||||||
|
o "dn" is the current value of the dyntick counter that is incremented
|
||||||
|
when entering or leaving dynticks idle state via NMI. If both
|
||||||
|
the "dt" and "dn" values are even, then this CPU is in dynticks
|
||||||
|
idle mode and may be ignored by RCU. If either of these two
|
||||||
|
counters is odd, then RCU must be alert to the possibility of
|
||||||
|
an RCU read-side critical section running on this CPU.
|
||||||
|
|
||||||
|
This field is displayed only for CONFIG_NO_HZ kernels.
|
||||||
|
|
||||||
|
o "df" is the number of times that some other CPU has forced a
|
||||||
|
quiescent state on behalf of this CPU due to this CPU being in
|
||||||
|
dynticks-idle state.
|
||||||
|
|
||||||
|
This field is displayed only for CONFIG_NO_HZ kernels.
|
||||||
|
|
||||||
|
o "of" is the number of times that some other CPU has forced a
|
||||||
|
quiescent state on behalf of this CPU due to this CPU being
|
||||||
|
offline. In a perfect world, this might neve happen, but it
|
||||||
|
turns out that offlining and onlining a CPU can take several grace
|
||||||
|
periods, and so there is likely to be an extended period of time
|
||||||
|
when RCU believes that the CPU is online when it really is not.
|
||||||
|
Please note that erring in the other direction (RCU believing a
|
||||||
|
CPU is offline when it is really alive and kicking) is a fatal
|
||||||
|
error, so it makes sense to err conservatively.
|
||||||
|
|
||||||
|
o "ri" is the number of times that RCU has seen fit to send a
|
||||||
|
reschedule IPI to this CPU in order to get it to report a
|
||||||
|
quiescent state.
|
||||||
|
|
||||||
|
o "ql" is the number of RCU callbacks currently residing on
|
||||||
|
this CPU. This is the total number of callbacks, regardless
|
||||||
|
of what state they are in (new, waiting for grace period to
|
||||||
|
start, waiting for grace period to end, ready to invoke).
|
||||||
|
|
||||||
|
o "b" is the batch limit for this CPU. If more than this number
|
||||||
|
of RCU callbacks is ready to invoke, then the remainder will
|
||||||
|
be deferred.
|
||||||
|
|
||||||
|
|
||||||
|
The output of "cat rcu/rcugp" looks as follows:
|
||||||
|
|
||||||
|
rcu: completed=33062 gpnum=33063
|
||||||
|
rcu_bh: completed=464 gpnum=464
|
||||||
|
|
||||||
|
Again, this output is for both "rcu" and "rcu_bh". The fields are
|
||||||
|
taken from the rcu_state structure, and are as follows:
|
||||||
|
|
||||||
|
o "completed" is the number of grace periods that have completed.
|
||||||
|
It is comparable to the "c" field from rcu/rcudata in that a
|
||||||
|
CPU whose "c" field matches the value of "completed" is aware
|
||||||
|
that the corresponding RCU grace period has completed.
|
||||||
|
|
||||||
|
o "gpnum" is the number of grace periods that have started. It is
|
||||||
|
comparable to the "g" field from rcu/rcudata in that a CPU
|
||||||
|
whose "g" field matches the value of "gpnum" is aware that the
|
||||||
|
corresponding RCU grace period has started.
|
||||||
|
|
||||||
|
If these two fields are equal (as they are for "rcu_bh" above),
|
||||||
|
then there is no grace period in progress, in other words, RCU
|
||||||
|
is idle. On the other hand, if the two fields differ (as they
|
||||||
|
do for "rcu" above), then an RCU grace period is in progress.
|
||||||
|
|
||||||
|
|
||||||
|
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
|
||||||
|
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
|
||||||
|
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
|
||||||
|
|
||||||
|
This is once again split into "rcu" and "rcu_bh" portions. The fields are
|
||||||
|
as follows:
|
||||||
|
|
||||||
|
o "c" is exactly the same as "completed" under rcu/rcugp.
|
||||||
|
|
||||||
|
o "g" is exactly the same as "gpnum" under rcu/rcugp.
|
||||||
|
|
||||||
|
o "s" is the "signaled" state that drives force_quiescent_state()'s
|
||||||
|
state machine.
|
||||||
|
|
||||||
|
o "jfq" is the number of jiffies remaining for this grace period
|
||||||
|
before force_quiescent_state() is invoked to help push things
|
||||||
|
along. Note that CPUs in dyntick-idle mode thoughout the grace
|
||||||
|
period will not report on their own, but rather must be check by
|
||||||
|
some other CPU via force_quiescent_state().
|
||||||
|
|
||||||
|
o "j" is the low-order four hex digits of the jiffies counter.
|
||||||
|
Yes, Paul did run into a number of problems that turned out to
|
||||||
|
be due to the jiffies counter no longer counting. Why do you ask?
|
||||||
|
|
||||||
|
o "nfqs" is the number of calls to force_quiescent_state() since
|
||||||
|
boot.
|
||||||
|
|
||||||
|
o "nfqsng" is the number of useless calls to force_quiescent_state(),
|
||||||
|
where there wasn't actually a grace period active. This can
|
||||||
|
happen due to races. The number in parentheses is the difference
|
||||||
|
between "nfqs" and "nfqsng", or the number of times that
|
||||||
|
force_quiescent_state() actually did some real work.
|
||||||
|
|
||||||
|
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 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
|
||||||
|
as forming yet another level after the leaves. Note that there
|
||||||
|
might be either one, two, or three levels of rcu_node structures,
|
||||||
|
depending on the relationship between CONFIG_RCU_FANOUT and
|
||||||
|
CONFIG_NR_CPUS.
|
||||||
|
|
||||||
|
o The numbers separated by the "/" are the qsmask followed
|
||||||
|
by the qsmaskinit. The qsmask will have one bit
|
||||||
|
set for each entity in the next lower level that
|
||||||
|
has not yet checked in for the current grace period.
|
||||||
|
The qsmaskinit will have one bit for each entity that is
|
||||||
|
currently expected to check in during each grace period.
|
||||||
|
The value of qsmaskinit is assigned to that of qsmask
|
||||||
|
at the beginning of each grace period.
|
||||||
|
|
||||||
|
For example, for "rcu", the qsmask of the first entry
|
||||||
|
of the lowest level is 0x14, meaning that we are still
|
||||||
|
waiting for CPUs 2 and 4 to check in for the current
|
||||||
|
grace period.
|
||||||
|
|
||||||
|
o The numbers separated by the ":" are the range of CPUs
|
||||||
|
served by this struct rcu_node. This can be helpful
|
||||||
|
in working out how the hierarchy is wired together.
|
||||||
|
|
||||||
|
For example, the first entry at the lowest level shows
|
||||||
|
"0:5", indicating that it covers CPUs 0 through 5.
|
||||||
|
|
||||||
|
o The number after the "^" indicates the bit in the
|
||||||
|
next higher level rcu_node structure that this
|
||||||
|
rcu_node structure corresponds to.
|
||||||
|
|
||||||
|
For example, the first entry at the lowest level shows
|
||||||
|
"^0", indicating that it corresponds to bit zero in
|
||||||
|
the first entry at the middle level.
|
|
@ -392,6 +392,10 @@ int main(int argc, char *argv[])
|
||||||
goto err;
|
goto err;
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
if (!maskset && !tid && !containerset) {
|
||||||
|
usage();
|
||||||
|
goto err;
|
||||||
|
}
|
||||||
|
|
||||||
do {
|
do {
|
||||||
int i;
|
int i;
|
||||||
|
|
|
@ -0,0 +1,286 @@
|
||||||
|
MFP Configuration for PXA2xx/PXA3xx Processors
|
||||||
|
|
||||||
|
Eric Miao <eric.miao@marvell.com>
|
||||||
|
|
||||||
|
MFP stands for Multi-Function Pin, which is the pin-mux logic on PXA3xx and
|
||||||
|
later PXA series processors. This document describes the existing MFP API,
|
||||||
|
and how board/platform driver authors could make use of it.
|
||||||
|
|
||||||
|
Basic Concept
|
||||||
|
===============
|
||||||
|
|
||||||
|
Unlike the GPIO alternate function settings on PXA25x and PXA27x, a new MFP
|
||||||
|
mechanism is introduced from PXA3xx to completely move the pin-mux functions
|
||||||
|
out of the GPIO controller. In addition to pin-mux configurations, the MFP
|
||||||
|
also controls the low power state, driving strength, pull-up/down and event
|
||||||
|
detection of each pin. Below is a diagram of internal connections between
|
||||||
|
the MFP logic and the remaining SoC peripherals:
|
||||||
|
|
||||||
|
+--------+
|
||||||
|
| |--(GPIO19)--+
|
||||||
|
| GPIO | |
|
||||||
|
| |--(GPIO...) |
|
||||||
|
+--------+ |
|
||||||
|
| +---------+
|
||||||
|
+--------+ +------>| |
|
||||||
|
| PWM2 |--(PWM_OUT)-------->| MFP |
|
||||||
|
+--------+ +------>| |-------> to external PAD
|
||||||
|
| +---->| |
|
||||||
|
+--------+ | | +-->| |
|
||||||
|
| SSP2 |---(TXD)----+ | | +---------+
|
||||||
|
+--------+ | |
|
||||||
|
| |
|
||||||
|
+--------+ | |
|
||||||
|
| Keypad |--(MKOUT4)----+ |
|
||||||
|
+--------+ |
|
||||||
|
|
|
||||||
|
+--------+ |
|
||||||
|
| UART2 |---(TXD)--------+
|
||||||
|
+--------+
|
||||||
|
|
||||||
|
NOTE: the external pad is named as MFP_PIN_GPIO19, it doesn't necessarily
|
||||||
|
mean it's dedicated for GPIO19, only as a hint that internally this pin
|
||||||
|
can be routed from GPIO19 of the GPIO controller.
|
||||||
|
|
||||||
|
To better understand the change from PXA25x/PXA27x GPIO alternate function
|
||||||
|
to this new MFP mechanism, here are several key points:
|
||||||
|
|
||||||
|
1. GPIO controller on PXA3xx is now a dedicated controller, same as other
|
||||||
|
internal controllers like PWM, SSP and UART, with 128 internal signals
|
||||||
|
which can be routed to external through one or more MFPs (e.g. GPIO<0>
|
||||||
|
can be routed through either MFP_PIN_GPIO0 as well as MFP_PIN_GPIO0_2,
|
||||||
|
see arch/arm/mach-pxa/mach/include/mfp-pxa300.h)
|
||||||
|
|
||||||
|
2. Alternate function configuration is removed from this GPIO controller,
|
||||||
|
the remaining functions are pure GPIO-specific, i.e.
|
||||||
|
|
||||||
|
- GPIO signal level control
|
||||||
|
- GPIO direction control
|
||||||
|
- GPIO level change detection
|
||||||
|
|
||||||
|
3. Low power state for each pin is now controlled by MFP, this means the
|
||||||
|
PGSRx registers on PXA2xx are now useless on PXA3xx
|
||||||
|
|
||||||
|
4. Wakeup detection is now controlled by MFP, PWER does not control the
|
||||||
|
wakeup from GPIO(s) any more, depending on the sleeping state, ADxER
|
||||||
|
(as defined in pxa3xx-regs.h) controls the wakeup from MFP
|
||||||
|
|
||||||
|
NOTE: with such a clear separation of MFP and GPIO, by GPIO<xx> we normally
|
||||||
|
mean it is a GPIO signal, and by MFP<xxx> or pin xxx, we mean a physical
|
||||||
|
pad (or ball).
|
||||||
|
|
||||||
|
MFP API Usage
|
||||||
|
===============
|
||||||
|
|
||||||
|
For board code writers, here are some guidelines:
|
||||||
|
|
||||||
|
1. include ONE of the following header files in your <board>.c:
|
||||||
|
|
||||||
|
- #include <mach/mfp-pxa25x.h>
|
||||||
|
- #include <mach/mfp-pxa27x.h>
|
||||||
|
- #include <mach/mfp-pxa300.h>
|
||||||
|
- #include <mach/mfp-pxa320.h>
|
||||||
|
- #include <mach/mfp-pxa930.h>
|
||||||
|
|
||||||
|
NOTE: only one file in your <board>.c, depending on the processors used,
|
||||||
|
because pin configuration definitions may conflict in these file (i.e.
|
||||||
|
same name, different meaning and settings on different processors). E.g.
|
||||||
|
for zylonite platform, which support both PXA300/PXA310 and PXA320, two
|
||||||
|
separate files are introduced: zylonite_pxa300.c and zylonite_pxa320.c
|
||||||
|
(in addition to handle MFP configuration differences, they also handle
|
||||||
|
the other differences between the two combinations).
|
||||||
|
|
||||||
|
NOTE: PXA300 and PXA310 are almost identical in pin configurations (with
|
||||||
|
PXA310 supporting some additional ones), thus the difference is actually
|
||||||
|
covered in a single mfp-pxa300.h.
|
||||||
|
|
||||||
|
2. prepare an array for the initial pin configurations, e.g.:
|
||||||
|
|
||||||
|
static unsigned long mainstone_pin_config[] __initdata = {
|
||||||
|
/* Chip Select */
|
||||||
|
GPIO15_nCS_1,
|
||||||
|
|
||||||
|
/* LCD - 16bpp Active TFT */
|
||||||
|
GPIOxx_TFT_LCD_16BPP,
|
||||||
|
GPIO16_PWM0_OUT, /* Backlight */
|
||||||
|
|
||||||
|
/* MMC */
|
||||||
|
GPIO32_MMC_CLK,
|
||||||
|
GPIO112_MMC_CMD,
|
||||||
|
GPIO92_MMC_DAT_0,
|
||||||
|
GPIO109_MMC_DAT_1,
|
||||||
|
GPIO110_MMC_DAT_2,
|
||||||
|
GPIO111_MMC_DAT_3,
|
||||||
|
|
||||||
|
...
|
||||||
|
|
||||||
|
/* GPIO */
|
||||||
|
GPIO1_GPIO | WAKEUP_ON_EDGE_BOTH,
|
||||||
|
};
|
||||||
|
|
||||||
|
a) once the pin configurations are passed to pxa{2xx,3xx}_mfp_config(),
|
||||||
|
and written to the actual registers, they are useless and may discard,
|
||||||
|
adding '__initdata' will help save some additional bytes here.
|
||||||
|
|
||||||
|
b) when there is only one possible pin configurations for a component,
|
||||||
|
some simplified definitions can be used, e.g. GPIOxx_TFT_LCD_16BPP on
|
||||||
|
PXA25x and PXA27x processors
|
||||||
|
|
||||||
|
c) if by board design, a pin can be configured to wake up the system
|
||||||
|
from low power state, it can be 'OR'ed with any of:
|
||||||
|
|
||||||
|
WAKEUP_ON_EDGE_BOTH
|
||||||
|
WAKEUP_ON_EDGE_RISE
|
||||||
|
WAKEUP_ON_EDGE_FALL
|
||||||
|
WAKEUP_ON_LEVEL_HIGH - specifically for enabling of keypad GPIOs,
|
||||||
|
|
||||||
|
to indicate that this pin has the capability of wake-up the system,
|
||||||
|
and on which edge(s). This, however, doesn't necessarily mean the
|
||||||
|
pin _will_ wakeup the system, it will only when set_irq_wake() is
|
||||||
|
invoked with the corresponding GPIO IRQ (GPIO_IRQ(xx) or gpio_to_irq())
|
||||||
|
and eventually calls gpio_set_wake() for the actual register setting.
|
||||||
|
|
||||||
|
d) although PXA3xx MFP supports edge detection on each pin, the
|
||||||
|
internal logic will only wakeup the system when those specific bits
|
||||||
|
in ADxER registers are set, which can be well mapped to the
|
||||||
|
corresponding peripheral, thus set_irq_wake() can be called with
|
||||||
|
the peripheral IRQ to enable the wakeup.
|
||||||
|
|
||||||
|
|
||||||
|
MFP on PXA3xx
|
||||||
|
===============
|
||||||
|
|
||||||
|
Every external I/O pad on PXA3xx (excluding those for special purpose) has
|
||||||
|
one MFP logic associated, and is controlled by one MFP register (MFPR).
|
||||||
|
|
||||||
|
The MFPR has the following bit definitions (for PXA300/PXA310/PXA320):
|
||||||
|
|
||||||
|
31 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
|
||||||
|
+-------------------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||||||
|
| RESERVED |PS|PU|PD| DRIVE |SS|SD|SO|EC|EF|ER|--| AF_SEL |
|
||||||
|
+-------------------------+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
||||||
|
|
||||||
|
Bit 3: RESERVED
|
||||||
|
Bit 4: EDGE_RISE_EN - enable detection of rising edge on this pin
|
||||||
|
Bit 5: EDGE_FALL_EN - enable detection of falling edge on this pin
|
||||||
|
Bit 6: EDGE_CLEAR - disable edge detection on this pin
|
||||||
|
Bit 7: SLEEP_OE_N - enable outputs during low power modes
|
||||||
|
Bit 8: SLEEP_DATA - output data on the pin during low power modes
|
||||||
|
Bit 9: SLEEP_SEL - selection control for low power modes signals
|
||||||
|
Bit 13: PULLDOWN_EN - enable the internal pull-down resistor on this pin
|
||||||
|
Bit 14: PULLUP_EN - enable the internal pull-up resistor on this pin
|
||||||
|
Bit 15: PULL_SEL - pull state controlled by selected alternate function
|
||||||
|
(0) or by PULL{UP,DOWN}_EN bits (1)
|
||||||
|
|
||||||
|
Bit 0 - 2: AF_SEL - alternate function selection, 8 possibilities, from 0-7
|
||||||
|
Bit 10-12: DRIVE - drive strength and slew rate
|
||||||
|
0b000 - fast 1mA
|
||||||
|
0b001 - fast 2mA
|
||||||
|
0b002 - fast 3mA
|
||||||
|
0b003 - fast 4mA
|
||||||
|
0b004 - slow 6mA
|
||||||
|
0b005 - fast 6mA
|
||||||
|
0b006 - slow 10mA
|
||||||
|
0b007 - fast 10mA
|
||||||
|
|
||||||
|
MFP Design for PXA2xx/PXA3xx
|
||||||
|
==============================
|
||||||
|
|
||||||
|
Due to the difference of pin-mux handling between PXA2xx and PXA3xx, a unified
|
||||||
|
MFP API is introduced to cover both series of processors.
|
||||||
|
|
||||||
|
The basic idea of this design is to introduce definitions for all possible pin
|
||||||
|
configurations, these definitions are processor and platform independent, and
|
||||||
|
the actual API invoked to convert these definitions into register settings and
|
||||||
|
make them effective there-after.
|
||||||
|
|
||||||
|
Files Involved
|
||||||
|
--------------
|
||||||
|
|
||||||
|
- arch/arm/mach-pxa/include/mach/mfp.h
|
||||||
|
|
||||||
|
for
|
||||||
|
1. Unified pin definitions - enum constants for all configurable pins
|
||||||
|
2. processor-neutral bit definitions for a possible MFP configuration
|
||||||
|
|
||||||
|
- arch/arm/mach-pxa/include/mach/mfp-pxa3xx.h
|
||||||
|
|
||||||
|
for PXA3xx specific MFPR register bit definitions and PXA3xx common pin
|
||||||
|
configurations
|
||||||
|
|
||||||
|
- arch/arm/mach-pxa/include/mach/mfp-pxa2xx.h
|
||||||
|
|
||||||
|
for PXA2xx specific definitions and PXA25x/PXA27x common pin configurations
|
||||||
|
|
||||||
|
- arch/arm/mach-pxa/include/mach/mfp-pxa25x.h
|
||||||
|
arch/arm/mach-pxa/include/mach/mfp-pxa27x.h
|
||||||
|
arch/arm/mach-pxa/include/mach/mfp-pxa300.h
|
||||||
|
arch/arm/mach-pxa/include/mach/mfp-pxa320.h
|
||||||
|
arch/arm/mach-pxa/include/mach/mfp-pxa930.h
|
||||||
|
|
||||||
|
for processor specific definitions
|
||||||
|
|
||||||
|
- arch/arm/mach-pxa/mfp-pxa3xx.c
|
||||||
|
- arch/arm/mach-pxa/mfp-pxa2xx.c
|
||||||
|
|
||||||
|
for implementation of the pin configuration to take effect for the actual
|
||||||
|
processor.
|
||||||
|
|
||||||
|
Pin Configuration
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
The following comments are copied from mfp.h (see the actual source code
|
||||||
|
for most updated info)
|
||||||
|
|
||||||
|
/*
|
||||||
|
* a possible MFP configuration is represented by a 32-bit integer
|
||||||
|
*
|
||||||
|
* bit 0.. 9 - MFP Pin Number (1024 Pins Maximum)
|
||||||
|
* bit 10..12 - Alternate Function Selection
|
||||||
|
* bit 13..15 - Drive Strength
|
||||||
|
* bit 16..18 - Low Power Mode State
|
||||||
|
* bit 19..20 - Low Power Mode Edge Detection
|
||||||
|
* bit 21..22 - Run Mode Pull State
|
||||||
|
*
|
||||||
|
* to facilitate the definition, the following macros are provided
|
||||||
|
*
|
||||||
|
* MFP_CFG_DEFAULT - default MFP configuration value, with
|
||||||
|
* alternate function = 0,
|
||||||
|
* drive strength = fast 3mA (MFP_DS03X)
|
||||||
|
* low power mode = default
|
||||||
|
* edge detection = none
|
||||||
|
*
|
||||||
|
* MFP_CFG - default MFPR value with alternate function
|
||||||
|
* MFP_CFG_DRV - default MFPR value with alternate function and
|
||||||
|
* pin drive strength
|
||||||
|
* MFP_CFG_LPM - default MFPR value with alternate function and
|
||||||
|
* low power mode
|
||||||
|
* MFP_CFG_X - default MFPR value with alternate function,
|
||||||
|
* pin drive strength and low power mode
|
||||||
|
*/
|
||||||
|
|
||||||
|
Examples of pin configurations are:
|
||||||
|
|
||||||
|
#define GPIO94_SSP3_RXD MFP_CFG_X(GPIO94, AF1, DS08X, FLOAT)
|
||||||
|
|
||||||
|
which reads GPIO94 can be configured as SSP3_RXD, with alternate function
|
||||||
|
selection of 1, driving strength of 0b101, and a float state in low power
|
||||||
|
modes.
|
||||||
|
|
||||||
|
NOTE: this is the default setting of this pin being configured as SSP3_RXD
|
||||||
|
which can be modified a bit in board code, though it is not recommended to
|
||||||
|
do so, simply because this default setting is usually carefully encoded,
|
||||||
|
and is supposed to work in most cases.
|
||||||
|
|
||||||
|
Register Settings
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
Register settings on PXA3xx for a pin configuration is actually very
|
||||||
|
straight-forward, most bits can be converted directly into MFPR value
|
||||||
|
in a easier way. Two sets of MFPR values are calculated: the run-time
|
||||||
|
ones and the low power mode ones, to allow different settings.
|
||||||
|
|
||||||
|
The conversion from a generic pin configuration to the actual register
|
||||||
|
settings on PXA2xx is a bit complicated: many registers are involved,
|
||||||
|
including GAFRx, GPDRx, PGSRx, PWER, PKWR, PFER and PRER. Please see
|
||||||
|
mfp-pxa2xx.c for how the conversion is made.
|
|
@ -0,0 +1,45 @@
|
||||||
|
March 2008
|
||||||
|
Jan-Simon Moeller, dl9pf@gmx.de
|
||||||
|
|
||||||
|
|
||||||
|
How to deal with bad memory e.g. reported by memtest86+ ?
|
||||||
|
#########################################################
|
||||||
|
|
||||||
|
There are three possibilities I know of:
|
||||||
|
|
||||||
|
1) Reinsert/swap the memory modules
|
||||||
|
|
||||||
|
2) Buy new modules (best!) or try to exchange the memory
|
||||||
|
if you have spare-parts
|
||||||
|
|
||||||
|
3) Use BadRAM or memmap
|
||||||
|
|
||||||
|
This Howto is about number 3) .
|
||||||
|
|
||||||
|
|
||||||
|
BadRAM
|
||||||
|
######
|
||||||
|
BadRAM is the actively developed and available as kernel-patch
|
||||||
|
here: http://rick.vanrein.org/linux/badram/
|
||||||
|
|
||||||
|
For more details see the BadRAM documentation.
|
||||||
|
|
||||||
|
memmap
|
||||||
|
######
|
||||||
|
|
||||||
|
memmap is already in the kernel and usable as kernel-parameter at
|
||||||
|
boot-time. Its syntax is slightly strange and you may need to
|
||||||
|
calculate the values by yourself!
|
||||||
|
|
||||||
|
Syntax to exclude a memory area (see kernel-parameters.txt for details):
|
||||||
|
memmap=<size>$<address>
|
||||||
|
|
||||||
|
Example: memtest86+ reported here errors at address 0x18691458, 0x18698424 and
|
||||||
|
some others. All had 0x1869xxxx in common, so I chose a pattern of
|
||||||
|
0x18690000,0xffff0000.
|
||||||
|
|
||||||
|
With the numbers of the example above:
|
||||||
|
memmap=64K$0x18690000
|
||||||
|
or
|
||||||
|
memmap=0x10000$0x18690000
|
||||||
|
|
|
@ -9,3 +9,6 @@ cachefeatures.txt
|
||||||
|
|
||||||
Filesystems
|
Filesystems
|
||||||
- Requirements for mounting the root file system.
|
- Requirements for mounting the root file system.
|
||||||
|
|
||||||
|
bfin-gpio-note.txt
|
||||||
|
- Notes in developing/using bfin-gpio driver.
|
||||||
|
|
|
@ -0,0 +1,71 @@
|
||||||
|
/*
|
||||||
|
* File: Documentation/blackfin/bfin-gpio-note.txt
|
||||||
|
* Based on:
|
||||||
|
* Author:
|
||||||
|
*
|
||||||
|
* Created: $Id: bfin-gpio-note.txt 2008-11-24 16:42 grafyang $
|
||||||
|
* Description: This file contains the notes in developing/using bfin-gpio.
|
||||||
|
*
|
||||||
|
*
|
||||||
|
* Rev:
|
||||||
|
*
|
||||||
|
* Modified:
|
||||||
|
* Copyright 2004-2008 Analog Devices Inc.
|
||||||
|
*
|
||||||
|
* Bugs: Enter bugs at http://blackfin.uclinux.org/
|
||||||
|
*
|
||||||
|
*/
|
||||||
|
|
||||||
|
|
||||||
|
1. Blackfin GPIO introduction
|
||||||
|
|
||||||
|
There are many GPIO pins on Blackfin. Most of these pins are muxed to
|
||||||
|
multi-functions. They can be configured as peripheral, or just as GPIO,
|
||||||
|
configured to input with interrupt enabled, or output.
|
||||||
|
|
||||||
|
For detailed information, please see "arch/blackfin/kernel/bfin_gpio.c",
|
||||||
|
or the relevant HRM.
|
||||||
|
|
||||||
|
|
||||||
|
2. Avoiding resource conflict
|
||||||
|
|
||||||
|
Followed function groups are used to avoiding resource conflict,
|
||||||
|
- Use the pin as peripheral,
|
||||||
|
int peripheral_request(unsigned short per, const char *label);
|
||||||
|
int peripheral_request_list(const unsigned short per[], const char *label);
|
||||||
|
void peripheral_free(unsigned short per);
|
||||||
|
void peripheral_free_list(const unsigned short per[]);
|
||||||
|
- Use the pin as GPIO,
|
||||||
|
int bfin_gpio_request(unsigned gpio, const char *label);
|
||||||
|
void bfin_gpio_free(unsigned gpio);
|
||||||
|
- Use the pin as GPIO interrupt,
|
||||||
|
int bfin_gpio_irq_request(unsigned gpio, const char *label);
|
||||||
|
void bfin_gpio_irq_free(unsigned gpio);
|
||||||
|
|
||||||
|
The request functions will record the function state for a certain pin,
|
||||||
|
the free functions will clear it's function state.
|
||||||
|
Once a pin is requested, it can't be requested again before it is freed by
|
||||||
|
previous caller, otherwise kernel will dump stacks, and the request
|
||||||
|
function fail.
|
||||||
|
These functions are wrapped by other functions, most of the users need not
|
||||||
|
care.
|
||||||
|
|
||||||
|
|
||||||
|
3. But there are some exceptions
|
||||||
|
- Kernel permit the identical GPIO be requested both as GPIO and GPIO
|
||||||
|
interrut.
|
||||||
|
Some drivers, like gpio-keys, need this behavior. Kernel only print out
|
||||||
|
warning messages like,
|
||||||
|
bfin-gpio: GPIO 24 is already reserved by gpio-keys: BTN0, and you are
|
||||||
|
configuring it as IRQ!
|
||||||
|
|
||||||
|
Note: Consider the case that, if there are two drivers need the
|
||||||
|
identical GPIO, one of them use it as GPIO, the other use it as
|
||||||
|
GPIO interrupt. This will really cause resource conflict. So if
|
||||||
|
there is any abnormal driver behavior, please check the bfin-gpio
|
||||||
|
warning messages.
|
||||||
|
|
||||||
|
- Kernel permit the identical GPIO be requested from the same driver twice.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -914,7 +914,7 @@ I/O scheduler, a.k.a. elevator, is implemented in two layers. Generic dispatch
|
||||||
queue and specific I/O schedulers. Unless stated otherwise, elevator is used
|
queue and specific I/O schedulers. Unless stated otherwise, elevator is used
|
||||||
to refer to both parts and I/O scheduler to specific I/O schedulers.
|
to refer to both parts and I/O scheduler to specific I/O schedulers.
|
||||||
|
|
||||||
Block layer implements generic dispatch queue in ll_rw_blk.c and elevator.c.
|
Block layer implements generic dispatch queue in block/*.c.
|
||||||
The generic dispatch queue is responsible for properly ordering barrier
|
The generic dispatch queue is responsible for properly ordering barrier
|
||||||
requests, requeueing, handling non-fs requests and all other subtleties.
|
requests, requeueing, handling non-fs requests and all other subtleties.
|
||||||
|
|
||||||
|
@ -926,8 +926,8 @@ be built inside the kernel. Each queue can choose different one and can also
|
||||||
change to another one dynamically.
|
change to another one dynamically.
|
||||||
|
|
||||||
A block layer call to the i/o scheduler follows the convention elv_xxx(). This
|
A block layer call to the i/o scheduler follows the convention elv_xxx(). This
|
||||||
calls elevator_xxx_fn in the elevator switch (drivers/block/elevator.c). Oh,
|
calls elevator_xxx_fn in the elevator switch (block/elevator.c). Oh, xxx
|
||||||
xxx and xxx might not match exactly, but use your imagination. If an elevator
|
and xxx might not match exactly, but use your imagination. If an elevator
|
||||||
doesn't implement a function, the switch does nothing or some minimal house
|
doesn't implement a function, the switch does nothing or some minimal house
|
||||||
keeping work.
|
keeping work.
|
||||||
|
|
||||||
|
|
|
@ -1,7 +1,8 @@
|
||||||
CGROUPS
|
CGROUPS
|
||||||
-------
|
-------
|
||||||
|
|
||||||
Written by Paul Menage <menage@google.com> based on Documentation/cpusets.txt
|
Written by Paul Menage <menage@google.com> based on
|
||||||
|
Documentation/cgroups/cpusets.txt
|
||||||
|
|
||||||
Original copyright statements from cpusets.txt:
|
Original copyright statements from cpusets.txt:
|
||||||
Portions Copyright (C) 2004 BULL SA.
|
Portions Copyright (C) 2004 BULL SA.
|
||||||
|
@ -68,7 +69,7 @@ On their own, the only use for cgroups is for simple job
|
||||||
tracking. The intention is that other subsystems hook into the generic
|
tracking. The intention is that other subsystems hook into the generic
|
||||||
cgroup support to provide new attributes for cgroups, such as
|
cgroup support to provide new attributes for cgroups, such as
|
||||||
accounting/limiting the resources which processes in a cgroup can
|
accounting/limiting the resources which processes in a cgroup can
|
||||||
access. For example, cpusets (see Documentation/cpusets.txt) allows
|
access. For example, cpusets (see Documentation/cgroups/cpusets.txt) allows
|
||||||
you to associate a set of CPUs and a set of memory nodes with the
|
you to associate a set of CPUs and a set of memory nodes with the
|
||||||
tasks in each cgroup.
|
tasks in each cgroup.
|
||||||
|
|
||||||
|
@ -227,7 +228,6 @@ Each cgroup is represented by a directory in the cgroup file system
|
||||||
containing the following files describing that cgroup:
|
containing the following files describing that cgroup:
|
||||||
|
|
||||||
- tasks: list of tasks (by pid) attached to that cgroup
|
- tasks: list of tasks (by pid) attached to that cgroup
|
||||||
- releasable flag: cgroup currently removeable?
|
|
||||||
- notify_on_release flag: run the release agent on exit?
|
- notify_on_release flag: run the release agent on exit?
|
||||||
- release_agent: the path to use for release notifications (this file
|
- release_agent: the path to use for release notifications (this file
|
||||||
exists in the top cgroup only)
|
exists in the top cgroup only)
|
||||||
|
@ -360,7 +360,7 @@ Now you want to do something with this cgroup.
|
||||||
|
|
||||||
In this directory you can find several files:
|
In this directory you can find several files:
|
||||||
# ls
|
# ls
|
||||||
notify_on_release releasable tasks
|
notify_on_release tasks
|
||||||
(plus whatever files added by the attached subsystems)
|
(plus whatever files added by the attached subsystems)
|
||||||
|
|
||||||
Now attach your shell to this cgroup:
|
Now attach your shell to this cgroup:
|
||||||
|
@ -479,7 +479,6 @@ newly-created cgroup if an error occurs after this subsystem's
|
||||||
create() method has been called for the new cgroup).
|
create() method has been called for the new cgroup).
|
||||||
|
|
||||||
void pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp);
|
void pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp);
|
||||||
(cgroup_mutex held by caller)
|
|
||||||
|
|
||||||
Called before checking the reference count on each subsystem. This may
|
Called before checking the reference count on each subsystem. This may
|
||||||
be useful for subsystems which have some extra references even if
|
be useful for subsystems which have some extra references even if
|
||||||
|
@ -498,6 +497,7 @@ remain valid while the caller holds cgroup_mutex.
|
||||||
|
|
||||||
void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
void attach(struct cgroup_subsys *ss, struct cgroup *cgrp,
|
||||||
struct cgroup *old_cgrp, struct task_struct *task)
|
struct cgroup *old_cgrp, struct task_struct *task)
|
||||||
|
(cgroup_mutex held by caller)
|
||||||
|
|
||||||
Called after the task has been attached to the cgroup, to allow any
|
Called after the task has been attached to the cgroup, to allow any
|
||||||
post-attachment activity that requires memory allocations or blocking.
|
post-attachment activity that requires memory allocations or blocking.
|
||||||
|
@ -511,6 +511,7 @@ void exit(struct cgroup_subsys *ss, struct task_struct *task)
|
||||||
Called during task exit.
|
Called during task exit.
|
||||||
|
|
||||||
int populate(struct cgroup_subsys *ss, struct cgroup *cgrp)
|
int populate(struct cgroup_subsys *ss, struct cgroup *cgrp)
|
||||||
|
(cgroup_mutex held by caller)
|
||||||
|
|
||||||
Called after creation of a cgroup to allow a subsystem to populate
|
Called after creation of a cgroup to allow a subsystem to populate
|
||||||
the cgroup directory with file entries. The subsystem should make
|
the cgroup directory with file entries. The subsystem should make
|
||||||
|
@ -520,6 +521,7 @@ method can return an error code, the error code is currently not
|
||||||
always handled well.
|
always handled well.
|
||||||
|
|
||||||
void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp)
|
void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp)
|
||||||
|
(cgroup_mutex held by caller)
|
||||||
|
|
||||||
Called at the end of cgroup_clone() to do any paramater
|
Called at the end of cgroup_clone() to do any paramater
|
||||||
initialization which might be required before a task could attach. For
|
initialization which might be required before a task could attach. For
|
||||||
|
@ -527,7 +529,7 @@ example in cpusets, no task may attach before 'cpus' and 'mems' are set
|
||||||
up.
|
up.
|
||||||
|
|
||||||
void bind(struct cgroup_subsys *ss, struct cgroup *root)
|
void bind(struct cgroup_subsys *ss, struct cgroup *root)
|
||||||
(cgroup_mutex held by caller)
|
(cgroup_mutex and ss->hierarchy_mutex held by caller)
|
||||||
|
|
||||||
Called when a cgroup subsystem is rebound to a different hierarchy
|
Called when a cgroup subsystem is rebound to a different hierarchy
|
||||||
and root cgroup. Currently this will only involve movement between
|
and root cgroup. Currently this will only involve movement between
|
||||||
|
|
|
@ -0,0 +1,32 @@
|
||||||
|
CPU Accounting Controller
|
||||||
|
-------------------------
|
||||||
|
|
||||||
|
The CPU accounting controller is used to group tasks using cgroups and
|
||||||
|
account the CPU usage of these groups of tasks.
|
||||||
|
|
||||||
|
The CPU accounting controller supports multi-hierarchy groups. An accounting
|
||||||
|
group accumulates the CPU usage of all of its child groups and the tasks
|
||||||
|
directly present in its group.
|
||||||
|
|
||||||
|
Accounting groups can be created by first mounting the cgroup filesystem.
|
||||||
|
|
||||||
|
# mkdir /cgroups
|
||||||
|
# mount -t cgroup -ocpuacct none /cgroups
|
||||||
|
|
||||||
|
With the above step, the initial or the parent accounting group
|
||||||
|
becomes visible at /cgroups. At bootup, this group includes all the
|
||||||
|
tasks in the system. /cgroups/tasks lists the tasks in this cgroup.
|
||||||
|
/cgroups/cpuacct.usage gives the CPU time (in nanoseconds) obtained by
|
||||||
|
this group which is essentially the CPU time obtained by all the tasks
|
||||||
|
in the system.
|
||||||
|
|
||||||
|
New accounting groups can be created under the parent group /cgroups.
|
||||||
|
|
||||||
|
# cd /cgroups
|
||||||
|
# mkdir g1
|
||||||
|
# echo $$ > g1
|
||||||
|
|
||||||
|
The above steps create a new group g1 and move the current shell
|
||||||
|
process (bash) into it. CPU time consumed by this bash and its children
|
||||||
|
can be obtained from g1/cpuacct.usage and the same is accumulated in
|
||||||
|
/cgroups/cpuacct.usage also.
|
|
@ -0,0 +1,342 @@
|
||||||
|
Memory Resource Controller(Memcg) Implementation Memo.
|
||||||
|
Last Updated: 2008/12/15
|
||||||
|
Base Kernel Version: based on 2.6.28-rc8-mm.
|
||||||
|
|
||||||
|
Because VM is getting complex (one of reasons is memcg...), memcg's behavior
|
||||||
|
is complex. This is a document for memcg's internal behavior.
|
||||||
|
Please note that implementation details can be changed.
|
||||||
|
|
||||||
|
(*) Topics on API should be in Documentation/cgroups/memory.txt)
|
||||||
|
|
||||||
|
0. How to record usage ?
|
||||||
|
2 objects are used.
|
||||||
|
|
||||||
|
page_cgroup ....an object per page.
|
||||||
|
Allocated at boot or memory hotplug. Freed at memory hot removal.
|
||||||
|
|
||||||
|
swap_cgroup ... an entry per swp_entry.
|
||||||
|
Allocated at swapon(). Freed at swapoff().
|
||||||
|
|
||||||
|
The page_cgroup has USED bit and double count against a page_cgroup never
|
||||||
|
occurs. swap_cgroup is used only when a charged page is swapped-out.
|
||||||
|
|
||||||
|
1. Charge
|
||||||
|
|
||||||
|
a page/swp_entry may be charged (usage += PAGE_SIZE) at
|
||||||
|
|
||||||
|
mem_cgroup_newpage_charge()
|
||||||
|
Called at new page fault and Copy-On-Write.
|
||||||
|
|
||||||
|
mem_cgroup_try_charge_swapin()
|
||||||
|
Called at do_swap_page() (page fault on swap entry) and swapoff.
|
||||||
|
Followed by charge-commit-cancel protocol. (With swap accounting)
|
||||||
|
At commit, a charge recorded in swap_cgroup is removed.
|
||||||
|
|
||||||
|
mem_cgroup_cache_charge()
|
||||||
|
Called at add_to_page_cache()
|
||||||
|
|
||||||
|
mem_cgroup_cache_charge_swapin()
|
||||||
|
Called at shmem's swapin.
|
||||||
|
|
||||||
|
mem_cgroup_prepare_migration()
|
||||||
|
Called before migration. "extra" charge is done and followed by
|
||||||
|
charge-commit-cancel protocol.
|
||||||
|
At commit, charge against oldpage or newpage will be committed.
|
||||||
|
|
||||||
|
2. Uncharge
|
||||||
|
a page/swp_entry may be uncharged (usage -= PAGE_SIZE) by
|
||||||
|
|
||||||
|
mem_cgroup_uncharge_page()
|
||||||
|
Called when an anonymous page is fully unmapped. I.e., mapcount goes
|
||||||
|
to 0. If the page is SwapCache, uncharge is delayed until
|
||||||
|
mem_cgroup_uncharge_swapcache().
|
||||||
|
|
||||||
|
mem_cgroup_uncharge_cache_page()
|
||||||
|
Called when a page-cache is deleted from radix-tree. If the page is
|
||||||
|
SwapCache, uncharge is delayed until mem_cgroup_uncharge_swapcache().
|
||||||
|
|
||||||
|
mem_cgroup_uncharge_swapcache()
|
||||||
|
Called when SwapCache is removed from radix-tree. The charge itself
|
||||||
|
is moved to swap_cgroup. (If mem+swap controller is disabled, no
|
||||||
|
charge to swap occurs.)
|
||||||
|
|
||||||
|
mem_cgroup_uncharge_swap()
|
||||||
|
Called when swp_entry's refcnt goes down to 0. A charge against swap
|
||||||
|
disappears.
|
||||||
|
|
||||||
|
mem_cgroup_end_migration(old, new)
|
||||||
|
At success of migration old is uncharged (if necessary), a charge
|
||||||
|
to new page is committed. At failure, charge to old page is committed.
|
||||||
|
|
||||||
|
3. charge-commit-cancel
|
||||||
|
In some case, we can't know this "charge" is valid or not at charging
|
||||||
|
(because of races).
|
||||||
|
To handle such case, there are charge-commit-cancel functions.
|
||||||
|
mem_cgroup_try_charge_XXX
|
||||||
|
mem_cgroup_commit_charge_XXX
|
||||||
|
mem_cgroup_cancel_charge_XXX
|
||||||
|
these are used in swap-in and migration.
|
||||||
|
|
||||||
|
At try_charge(), there are no flags to say "this page is charged".
|
||||||
|
at this point, usage += PAGE_SIZE.
|
||||||
|
|
||||||
|
At commit(), the function checks the page should be charged or not
|
||||||
|
and set flags or avoid charging.(usage -= PAGE_SIZE)
|
||||||
|
|
||||||
|
At cancel(), simply usage -= PAGE_SIZE.
|
||||||
|
|
||||||
|
Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
||||||
|
|
||||||
|
4. Anonymous
|
||||||
|
Anonymous page is newly allocated at
|
||||||
|
- page fault into MAP_ANONYMOUS mapping.
|
||||||
|
- Copy-On-Write.
|
||||||
|
It is charged right after it's allocated before doing any page table
|
||||||
|
related operations. Of course, it's uncharged when another page is used
|
||||||
|
for the fault address.
|
||||||
|
|
||||||
|
At freeing anonymous page (by exit() or munmap()), zap_pte() is called
|
||||||
|
and pages for ptes are freed one by one.(see mm/memory.c). Uncharges
|
||||||
|
are done at page_remove_rmap() when page_mapcount() goes down to 0.
|
||||||
|
|
||||||
|
Another page freeing is by page-reclaim (vmscan.c) and anonymous
|
||||||
|
pages are swapped out. In this case, the page is marked as
|
||||||
|
PageSwapCache(). uncharge() routine doesn't uncharge the page marked
|
||||||
|
as SwapCache(). It's delayed until __delete_from_swap_cache().
|
||||||
|
|
||||||
|
4.1 Swap-in.
|
||||||
|
At swap-in, the page is taken from swap-cache. There are 2 cases.
|
||||||
|
|
||||||
|
(a) If the SwapCache is newly allocated and read, it has no charges.
|
||||||
|
(b) If the SwapCache has been mapped by processes, it has been
|
||||||
|
charged already.
|
||||||
|
|
||||||
|
This swap-in is one of the most complicated work. In do_swap_page(),
|
||||||
|
following events occur when pte is unchanged.
|
||||||
|
|
||||||
|
(1) the page (SwapCache) is looked up.
|
||||||
|
(2) lock_page()
|
||||||
|
(3) try_charge_swapin()
|
||||||
|
(4) reuse_swap_page() (may call delete_swap_cache())
|
||||||
|
(5) commit_charge_swapin()
|
||||||
|
(6) swap_free().
|
||||||
|
|
||||||
|
Considering following situation for example.
|
||||||
|
|
||||||
|
(A) The page has not been charged before (2) and reuse_swap_page()
|
||||||
|
doesn't call delete_from_swap_cache().
|
||||||
|
(B) The page has not been charged before (2) and reuse_swap_page()
|
||||||
|
calls delete_from_swap_cache().
|
||||||
|
(C) The page has been charged before (2) and reuse_swap_page() doesn't
|
||||||
|
call delete_from_swap_cache().
|
||||||
|
(D) The page has been charged before (2) and reuse_swap_page() calls
|
||||||
|
delete_from_swap_cache().
|
||||||
|
|
||||||
|
memory.usage/memsw.usage changes to this page/swp_entry will be
|
||||||
|
Case (A) (B) (C) (D)
|
||||||
|
Event
|
||||||
|
Before (2) 0/ 1 0/ 1 1/ 1 1/ 1
|
||||||
|
===========================================
|
||||||
|
(3) +1/+1 +1/+1 +1/+1 +1/+1
|
||||||
|
(4) - 0/ 0 - -1/ 0
|
||||||
|
(5) 0/-1 0/ 0 -1/-1 0/ 0
|
||||||
|
(6) - 0/-1 - 0/-1
|
||||||
|
===========================================
|
||||||
|
Result 1/ 1 1/ 1 1/ 1 1/ 1
|
||||||
|
|
||||||
|
In any cases, charges to this page should be 1/ 1.
|
||||||
|
|
||||||
|
4.2 Swap-out.
|
||||||
|
At swap-out, typical state transition is below.
|
||||||
|
|
||||||
|
(a) add to swap cache. (marked as SwapCache)
|
||||||
|
swp_entry's refcnt += 1.
|
||||||
|
(b) fully unmapped.
|
||||||
|
swp_entry's refcnt += # of ptes.
|
||||||
|
(c) write back to swap.
|
||||||
|
(d) delete from swap cache. (remove from SwapCache)
|
||||||
|
swp_entry's refcnt -= 1.
|
||||||
|
|
||||||
|
|
||||||
|
At (b), the page is marked as SwapCache and not uncharged.
|
||||||
|
At (d), the page is removed from SwapCache and a charge in page_cgroup
|
||||||
|
is moved to swap_cgroup.
|
||||||
|
|
||||||
|
Finally, at task exit,
|
||||||
|
(e) zap_pte() is called and swp_entry's refcnt -=1 -> 0.
|
||||||
|
Here, a charge in swap_cgroup disappears.
|
||||||
|
|
||||||
|
5. Page Cache
|
||||||
|
Page Cache is charged at
|
||||||
|
- add_to_page_cache_locked().
|
||||||
|
|
||||||
|
uncharged at
|
||||||
|
- __remove_from_page_cache().
|
||||||
|
|
||||||
|
The logic is very clear. (About migration, see below)
|
||||||
|
Note: __remove_from_page_cache() is called by remove_from_page_cache()
|
||||||
|
and __remove_mapping().
|
||||||
|
|
||||||
|
6. Shmem(tmpfs) Page Cache
|
||||||
|
Memcg's charge/uncharge have special handlers of shmem. The best way
|
||||||
|
to understand shmem's page state transition is to read mm/shmem.c.
|
||||||
|
But brief explanation of the behavior of memcg around shmem will be
|
||||||
|
helpful to understand the logic.
|
||||||
|
|
||||||
|
Shmem's page (just leaf page, not direct/indirect block) can be on
|
||||||
|
- radix-tree of shmem's inode.
|
||||||
|
- SwapCache.
|
||||||
|
- Both on radix-tree and SwapCache. This happens at swap-in
|
||||||
|
and swap-out,
|
||||||
|
|
||||||
|
It's charged when...
|
||||||
|
- A new page is added to shmem's radix-tree.
|
||||||
|
- A swp page is read. (move a charge from swap_cgroup to page_cgroup)
|
||||||
|
It's uncharged when
|
||||||
|
- A page is removed from radix-tree and not SwapCache.
|
||||||
|
- When SwapCache is removed, a charge is moved to swap_cgroup.
|
||||||
|
- When swp_entry's refcnt goes down to 0, a charge in swap_cgroup
|
||||||
|
disappears.
|
||||||
|
|
||||||
|
7. Page Migration
|
||||||
|
One of the most complicated functions is page-migration-handler.
|
||||||
|
Memcg has 2 routines. Assume that we are migrating a page's contents
|
||||||
|
from OLDPAGE to NEWPAGE.
|
||||||
|
|
||||||
|
Usual migration logic is..
|
||||||
|
(a) remove the page from LRU.
|
||||||
|
(b) allocate NEWPAGE (migration target)
|
||||||
|
(c) lock by lock_page().
|
||||||
|
(d) unmap all mappings.
|
||||||
|
(e-1) If necessary, replace entry in radix-tree.
|
||||||
|
(e-2) move contents of a page.
|
||||||
|
(f) map all mappings again.
|
||||||
|
(g) pushback the page to LRU.
|
||||||
|
(-) OLDPAGE will be freed.
|
||||||
|
|
||||||
|
Before (g), memcg should complete all necessary charge/uncharge to
|
||||||
|
NEWPAGE/OLDPAGE.
|
||||||
|
|
||||||
|
The point is....
|
||||||
|
- If OLDPAGE is anonymous, all charges will be dropped at (d) because
|
||||||
|
try_to_unmap() drops all mapcount and the page will not be
|
||||||
|
SwapCache.
|
||||||
|
|
||||||
|
- If OLDPAGE is SwapCache, charges will be kept at (g) because
|
||||||
|
__delete_from_swap_cache() isn't called at (e-1)
|
||||||
|
|
||||||
|
- If OLDPAGE is page-cache, charges will be kept at (g) because
|
||||||
|
remove_from_swap_cache() isn't called at (e-1)
|
||||||
|
|
||||||
|
memcg provides following hooks.
|
||||||
|
|
||||||
|
- mem_cgroup_prepare_migration(OLDPAGE)
|
||||||
|
Called after (b) to account a charge (usage += PAGE_SIZE) against
|
||||||
|
memcg which OLDPAGE belongs to.
|
||||||
|
|
||||||
|
- mem_cgroup_end_migration(OLDPAGE, NEWPAGE)
|
||||||
|
Called after (f) before (g).
|
||||||
|
If OLDPAGE is used, commit OLDPAGE again. If OLDPAGE is already
|
||||||
|
charged, a charge by prepare_migration() is automatically canceled.
|
||||||
|
If NEWPAGE is used, commit NEWPAGE and uncharge OLDPAGE.
|
||||||
|
|
||||||
|
But zap_pte() (by exit or munmap) can be called while migration,
|
||||||
|
we have to check if OLDPAGE/NEWPAGE is a valid page after commit().
|
||||||
|
|
||||||
|
8. LRU
|
||||||
|
Each memcg has its own private LRU. Now, it's handling is under global
|
||||||
|
VM's control (means that it's handled under global zone->lru_lock).
|
||||||
|
Almost all routines around memcg's LRU is called by global LRU's
|
||||||
|
list management functions under zone->lru_lock().
|
||||||
|
|
||||||
|
A special function is mem_cgroup_isolate_pages(). This scans
|
||||||
|
memcg's private LRU and call __isolate_lru_page() to extract a page
|
||||||
|
from LRU.
|
||||||
|
(By __isolate_lru_page(), the page is removed from both of global and
|
||||||
|
private LRU.)
|
||||||
|
|
||||||
|
|
||||||
|
9. Typical Tests.
|
||||||
|
|
||||||
|
Tests for racy cases.
|
||||||
|
|
||||||
|
9.1 Small limit to memcg.
|
||||||
|
When you do test to do racy case, it's good test to set memcg's limit
|
||||||
|
to be very small rather than GB. Many races found in the test under
|
||||||
|
xKB or xxMB limits.
|
||||||
|
(Memory behavior under GB and Memory behavior under MB shows very
|
||||||
|
different situation.)
|
||||||
|
|
||||||
|
9.2 Shmem
|
||||||
|
Historically, memcg's shmem handling was poor and we saw some amount
|
||||||
|
of troubles here. This is because shmem is page-cache but can be
|
||||||
|
SwapCache. Test with shmem/tmpfs is always good test.
|
||||||
|
|
||||||
|
9.3 Migration
|
||||||
|
For NUMA, migration is an another special case. To do easy test, cpuset
|
||||||
|
is useful. Following is a sample script to do migration.
|
||||||
|
|
||||||
|
mount -t cgroup -o cpuset none /opt/cpuset
|
||||||
|
|
||||||
|
mkdir /opt/cpuset/01
|
||||||
|
echo 1 > /opt/cpuset/01/cpuset.cpus
|
||||||
|
echo 0 > /opt/cpuset/01/cpuset.mems
|
||||||
|
echo 1 > /opt/cpuset/01/cpuset.memory_migrate
|
||||||
|
mkdir /opt/cpuset/02
|
||||||
|
echo 1 > /opt/cpuset/02/cpuset.cpus
|
||||||
|
echo 1 > /opt/cpuset/02/cpuset.mems
|
||||||
|
echo 1 > /opt/cpuset/02/cpuset.memory_migrate
|
||||||
|
|
||||||
|
In above set, when you moves a task from 01 to 02, page migration to
|
||||||
|
node 0 to node 1 will occur. Following is a script to migrate all
|
||||||
|
under cpuset.
|
||||||
|
--
|
||||||
|
move_task()
|
||||||
|
{
|
||||||
|
for pid in $1
|
||||||
|
do
|
||||||
|
/bin/echo $pid >$2/tasks 2>/dev/null
|
||||||
|
echo -n $pid
|
||||||
|
echo -n " "
|
||||||
|
done
|
||||||
|
echo END
|
||||||
|
}
|
||||||
|
|
||||||
|
G1_TASK=`cat ${G1}/tasks`
|
||||||
|
G2_TASK=`cat ${G2}/tasks`
|
||||||
|
move_task "${G1_TASK}" ${G2} &
|
||||||
|
--
|
||||||
|
9.4 Memory hotplug.
|
||||||
|
memory hotplug test is one of good test.
|
||||||
|
to offline memory, do following.
|
||||||
|
# echo offline > /sys/devices/system/memory/memoryXXX/state
|
||||||
|
(XXX is the place of memory)
|
||||||
|
This is an easy way to test page migration, too.
|
||||||
|
|
||||||
|
9.5 mkdir/rmdir
|
||||||
|
When using hierarchy, mkdir/rmdir test should be done.
|
||||||
|
Use tests like the following.
|
||||||
|
|
||||||
|
echo 1 >/opt/cgroup/01/memory/use_hierarchy
|
||||||
|
mkdir /opt/cgroup/01/child_a
|
||||||
|
mkdir /opt/cgroup/01/child_b
|
||||||
|
|
||||||
|
set limit to 01.
|
||||||
|
add limit to 01/child_b
|
||||||
|
run jobs under child_a and child_b
|
||||||
|
|
||||||
|
create/delete following groups at random while jobs are running.
|
||||||
|
/opt/cgroup/01/child_a/child_aa
|
||||||
|
/opt/cgroup/01/child_b/child_bb
|
||||||
|
/opt/cgroup/01/child_c
|
||||||
|
|
||||||
|
running new jobs in new group is also good.
|
||||||
|
|
||||||
|
9.6 Mount with other subsystems.
|
||||||
|
Mounting with other subsystems is a good test because there is a
|
||||||
|
race and lock dependency with other cgroup subsystems.
|
||||||
|
|
||||||
|
example)
|
||||||
|
# mount -t cgroup none /cgroup -t cpuset,memory,cpu,devices
|
||||||
|
|
||||||
|
and do task move, mkdir, rmdir etc...under this.
|
|
@ -137,7 +137,32 @@ behind this approach is that a cgroup that aggressively uses a shared
|
||||||
page will eventually get charged for it (once it is uncharged from
|
page will eventually get charged for it (once it is uncharged from
|
||||||
the cgroup that brought it in -- this will happen on memory pressure).
|
the cgroup that brought it in -- this will happen on memory pressure).
|
||||||
|
|
||||||
2.4 Reclaim
|
Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used..
|
||||||
|
When you do swapoff and make swapped-out pages of shmem(tmpfs) to
|
||||||
|
be backed into memory in force, charges for pages are accounted against the
|
||||||
|
caller of swapoff rather than the users of shmem.
|
||||||
|
|
||||||
|
|
||||||
|
2.4 Swap Extension (CONFIG_CGROUP_MEM_RES_CTLR_SWAP)
|
||||||
|
Swap Extension allows you to record charge for swap. A swapped-in page is
|
||||||
|
charged back to original page allocator if possible.
|
||||||
|
|
||||||
|
When swap is accounted, following files are added.
|
||||||
|
- memory.memsw.usage_in_bytes.
|
||||||
|
- memory.memsw.limit_in_bytes.
|
||||||
|
|
||||||
|
usage of mem+swap is limited by memsw.limit_in_bytes.
|
||||||
|
|
||||||
|
Note: why 'mem+swap' rather than swap.
|
||||||
|
The global LRU(kswapd) can swap out arbitrary pages. Swap-out means
|
||||||
|
to move account from memory to swap...there is no change in usage of
|
||||||
|
mem+swap.
|
||||||
|
|
||||||
|
In other words, when we want to limit the usage of swap without affecting
|
||||||
|
global LRU, mem+swap limit is better than just limiting swap from OS point
|
||||||
|
of view.
|
||||||
|
|
||||||
|
2.5 Reclaim
|
||||||
|
|
||||||
Each cgroup maintains a per cgroup LRU that consists of an active
|
Each cgroup maintains a per cgroup LRU that consists of an active
|
||||||
and inactive list. When a cgroup goes over its limit, we first try
|
and inactive list. When a cgroup goes over its limit, we first try
|
||||||
|
@ -207,12 +232,6 @@ exceeded.
|
||||||
The memory.stat file gives accounting information. Now, the number of
|
The memory.stat file gives accounting information. Now, the number of
|
||||||
caches, RSS and Active pages/Inactive pages are shown.
|
caches, RSS and Active pages/Inactive pages are shown.
|
||||||
|
|
||||||
The memory.force_empty gives an interface to drop *all* charges by force.
|
|
||||||
|
|
||||||
# echo 1 > memory.force_empty
|
|
||||||
|
|
||||||
will drop all charges in cgroup. Currently, this is maintained for test.
|
|
||||||
|
|
||||||
4. Testing
|
4. Testing
|
||||||
|
|
||||||
Balbir posted lmbench, AIM9, LTP and vmmstress results [10] and [11].
|
Balbir posted lmbench, AIM9, LTP and vmmstress results [10] and [11].
|
||||||
|
@ -242,10 +261,106 @@ reclaimed.
|
||||||
|
|
||||||
A cgroup can be removed by rmdir, but as discussed in sections 4.1 and 4.2, a
|
A cgroup can be removed by rmdir, but as discussed in sections 4.1 and 4.2, a
|
||||||
cgroup might have some charge associated with it, even though all
|
cgroup might have some charge associated with it, even though all
|
||||||
tasks have migrated away from it. Such charges are automatically dropped at
|
tasks have migrated away from it.
|
||||||
rmdir() if there are no tasks.
|
Such charges are freed(at default) or moved to its parent. When moved,
|
||||||
|
both of RSS and CACHES are moved to parent.
|
||||||
|
If both of them are busy, rmdir() returns -EBUSY. See 5.1 Also.
|
||||||
|
|
||||||
5. TODO
|
Charges recorded in swap information is not updated at removal of cgroup.
|
||||||
|
Recorded information is discarded and a cgroup which uses swap (swapcache)
|
||||||
|
will be charged as a new owner of it.
|
||||||
|
|
||||||
|
|
||||||
|
5. Misc. interfaces.
|
||||||
|
|
||||||
|
5.1 force_empty
|
||||||
|
memory.force_empty interface is provided to make cgroup's memory usage empty.
|
||||||
|
You can use this interface only when the cgroup has no tasks.
|
||||||
|
When writing anything to this
|
||||||
|
|
||||||
|
# echo 0 > memory.force_empty
|
||||||
|
|
||||||
|
Almost all pages tracked by this memcg will be unmapped and freed. Some of
|
||||||
|
pages cannot be freed because it's locked or in-use. Such pages are moved
|
||||||
|
to parent and this cgroup will be empty. But this may return -EBUSY in
|
||||||
|
some too busy case.
|
||||||
|
|
||||||
|
Typical use case of this interface is that calling this before rmdir().
|
||||||
|
Because rmdir() moves all pages to parent, some out-of-use page caches can be
|
||||||
|
moved to the parent. If you want to avoid that, force_empty will be useful.
|
||||||
|
|
||||||
|
5.2 stat file
|
||||||
|
memory.stat file includes following statistics (now)
|
||||||
|
cache - # of pages from page-cache and shmem.
|
||||||
|
rss - # of pages from anonymous memory.
|
||||||
|
pgpgin - # of event of charging
|
||||||
|
pgpgout - # of event of uncharging
|
||||||
|
active_anon - # of pages on active lru of anon, shmem.
|
||||||
|
inactive_anon - # of pages on active lru of anon, shmem
|
||||||
|
active_file - # of pages on active lru of file-cache
|
||||||
|
inactive_file - # of pages on inactive lru of file cache
|
||||||
|
unevictable - # of pages cannot be reclaimed.(mlocked etc)
|
||||||
|
|
||||||
|
Below is depend on CONFIG_DEBUG_VM.
|
||||||
|
inactive_ratio - VM inernal parameter. (see mm/page_alloc.c)
|
||||||
|
recent_rotated_anon - VM internal parameter. (see mm/vmscan.c)
|
||||||
|
recent_rotated_file - VM internal parameter. (see mm/vmscan.c)
|
||||||
|
recent_scanned_anon - VM internal parameter. (see mm/vmscan.c)
|
||||||
|
recent_scanned_file - VM internal parameter. (see mm/vmscan.c)
|
||||||
|
|
||||||
|
Memo:
|
||||||
|
recent_rotated means recent frequency of lru rotation.
|
||||||
|
recent_scanned means recent # of scans to lru.
|
||||||
|
showing for better debug please see the code for meanings.
|
||||||
|
|
||||||
|
|
||||||
|
5.3 swappiness
|
||||||
|
Similar to /proc/sys/vm/swappiness, but affecting a hierarchy of groups only.
|
||||||
|
|
||||||
|
Following cgroup's swapiness can't be changed.
|
||||||
|
- root cgroup (uses /proc/sys/vm/swappiness).
|
||||||
|
- a cgroup which uses hierarchy and it has child cgroup.
|
||||||
|
- a cgroup which uses hierarchy and not the root of hierarchy.
|
||||||
|
|
||||||
|
|
||||||
|
6. Hierarchy support
|
||||||
|
|
||||||
|
The memory controller supports a deep hierarchy and hierarchical accounting.
|
||||||
|
The hierarchy is created by creating the appropriate cgroups in the
|
||||||
|
cgroup filesystem. Consider for example, the following cgroup filesystem
|
||||||
|
hierarchy
|
||||||
|
|
||||||
|
root
|
||||||
|
/ | \
|
||||||
|
/ | \
|
||||||
|
a b c
|
||||||
|
| \
|
||||||
|
| \
|
||||||
|
d e
|
||||||
|
|
||||||
|
In the diagram above, with hierarchical accounting enabled, all memory
|
||||||
|
usage of e, is accounted to its ancestors up until the root (i.e, c and root),
|
||||||
|
that has memory.use_hierarchy enabled. If one of the ancestors goes over its
|
||||||
|
limit, the reclaim algorithm reclaims from the tasks in the ancestor and the
|
||||||
|
children of the ancestor.
|
||||||
|
|
||||||
|
6.1 Enabling hierarchical accounting and reclaim
|
||||||
|
|
||||||
|
The memory controller by default disables the hierarchy feature. Support
|
||||||
|
can be enabled by writing 1 to memory.use_hierarchy file of the root cgroup
|
||||||
|
|
||||||
|
# echo 1 > memory.use_hierarchy
|
||||||
|
|
||||||
|
The feature can be disabled by
|
||||||
|
|
||||||
|
# echo 0 > memory.use_hierarchy
|
||||||
|
|
||||||
|
NOTE1: Enabling/disabling will fail if the cgroup already has other
|
||||||
|
cgroups created below it.
|
||||||
|
|
||||||
|
NOTE2: This feature can be enabled/disabled per subtree.
|
||||||
|
|
||||||
|
7. TODO
|
||||||
|
|
||||||
1. Add support for accounting huge pages (as a separate controller)
|
1. Add support for accounting huge pages (as a separate controller)
|
||||||
2. Make per-cgroup scanner reclaim not-shared pages first
|
2. Make per-cgroup scanner reclaim not-shared pages first
|
|
@ -93,10 +93,8 @@ Several "PowerBook" and "iBook2" notebooks are supported.
|
||||||
1.5 SuperH
|
1.5 SuperH
|
||||||
----------
|
----------
|
||||||
|
|
||||||
The following SuperH processors are supported by cpufreq:
|
All SuperH processors supporting rate rounding through the clock
|
||||||
|
framework are supported by cpufreq.
|
||||||
SH-3
|
|
||||||
SH-4
|
|
||||||
|
|
||||||
1.6 Blackfin
|
1.6 Blackfin
|
||||||
------------
|
------------
|
||||||
|
|
|
@ -50,16 +50,17 @@ additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets
|
||||||
cpu_possible_map = cpu_present_map + additional_cpus
|
cpu_possible_map = cpu_present_map + additional_cpus
|
||||||
|
|
||||||
(*) Option valid only for following architectures
|
(*) Option valid only for following architectures
|
||||||
- x86_64, ia64
|
- ia64
|
||||||
|
|
||||||
ia64 and x86_64 use the number of disabled local apics in ACPI tables MADT
|
ia64 uses the number of disabled local apics in ACPI tables MADT to
|
||||||
to determine the number of potentially hot-pluggable cpus. The implementation
|
determine the number of potentially hot-pluggable cpus. The implementation
|
||||||
should only rely on this to count the # of cpus, but *MUST* not rely on the
|
should only rely on this to count the # of cpus, but *MUST* not rely
|
||||||
apicid values in those tables for disabled apics. In the event BIOS doesn't
|
on the apicid values in those tables for disabled apics. In the event
|
||||||
mark such hot-pluggable cpus as disabled entries, one could use this
|
BIOS doesn't mark such hot-pluggable cpus as disabled entries, one could
|
||||||
parameter "additional_cpus=x" to represent those cpus in the cpu_possible_map.
|
use this parameter "additional_cpus=x" to represent those cpus in the
|
||||||
|
cpu_possible_map.
|
||||||
|
|
||||||
possible_cpus=n [s390 only] use this to set hotpluggable cpus.
|
possible_cpus=n [s390,x86_64] use this to set hotpluggable cpus.
|
||||||
This option sets possible_cpus bits in
|
This option sets possible_cpus bits in
|
||||||
cpu_possible_map. Thus keeping the numbers of bits set
|
cpu_possible_map. Thus keeping the numbers of bits set
|
||||||
constant even if the machine gets rebooted.
|
constant even if the machine gets rebooted.
|
||||||
|
|
|
@ -31,3 +31,51 @@ not defined by include/asm-XXX/topology.h:
|
||||||
2) core_id: 0
|
2) core_id: 0
|
||||||
3) thread_siblings: just the given CPU
|
3) thread_siblings: just the given CPU
|
||||||
4) core_siblings: just the given CPU
|
4) core_siblings: just the given CPU
|
||||||
|
|
||||||
|
Additionally, cpu topology information is provided under
|
||||||
|
/sys/devices/system/cpu and includes these files. The internal
|
||||||
|
source for the output is in brackets ("[]").
|
||||||
|
|
||||||
|
kernel_max: the maximum cpu index allowed by the kernel configuration.
|
||||||
|
[NR_CPUS-1]
|
||||||
|
|
||||||
|
offline: cpus that are not online because they have been
|
||||||
|
HOTPLUGGED off (see cpu-hotplug.txt) or exceed the limit
|
||||||
|
of cpus allowed by the kernel configuration (kernel_max
|
||||||
|
above). [~cpu_online_mask + cpus >= NR_CPUS]
|
||||||
|
|
||||||
|
online: cpus that are online and being scheduled [cpu_online_mask]
|
||||||
|
|
||||||
|
possible: cpus that have been allocated resources and can be
|
||||||
|
brought online if they are present. [cpu_possible_mask]
|
||||||
|
|
||||||
|
present: cpus that have been identified as being present in the
|
||||||
|
system. [cpu_present_mask]
|
||||||
|
|
||||||
|
The format for the above output is compatible with cpulist_parse()
|
||||||
|
[see <linux/cpumask.h>]. Some examples follow.
|
||||||
|
|
||||||
|
In this example, there are 64 cpus in the system but cpus 32-63 exceed
|
||||||
|
the kernel max which is limited to 0..31 by the NR_CPUS config option
|
||||||
|
being 32. Note also that cpus 2 and 4-31 are not online but could be
|
||||||
|
brought online as they are both present and possible.
|
||||||
|
|
||||||
|
kernel_max: 31
|
||||||
|
offline: 2,4-31,32-63
|
||||||
|
online: 0-1,3
|
||||||
|
possible: 0-31
|
||||||
|
present: 0-31
|
||||||
|
|
||||||
|
In this example, the NR_CPUS config option is 128, but the kernel was
|
||||||
|
started with possible_cpus=144. There are 4 cpus in the system and cpu2
|
||||||
|
was manually taken offline (and is the only cpu that can be brought
|
||||||
|
online.)
|
||||||
|
|
||||||
|
kernel_max: 127
|
||||||
|
offline: 2,4-127,128-143
|
||||||
|
online: 0-1,3
|
||||||
|
possible: 0-127
|
||||||
|
present: 0-3
|
||||||
|
|
||||||
|
See cpu-hotplug.txt for the possible_cpus=NUM kernel start parameter
|
||||||
|
as well as more information on the various cpumask's.
|
||||||
|
|
|
@ -0,0 +1,582 @@
|
||||||
|
====================
|
||||||
|
CREDENTIALS IN LINUX
|
||||||
|
====================
|
||||||
|
|
||||||
|
By: David Howells <dhowells@redhat.com>
|
||||||
|
|
||||||
|
Contents:
|
||||||
|
|
||||||
|
(*) Overview.
|
||||||
|
|
||||||
|
(*) Types of credentials.
|
||||||
|
|
||||||
|
(*) File markings.
|
||||||
|
|
||||||
|
(*) Task credentials.
|
||||||
|
|
||||||
|
- Immutable credentials.
|
||||||
|
- Accessing task credentials.
|
||||||
|
- Accessing another task's credentials.
|
||||||
|
- Altering credentials.
|
||||||
|
- Managing credentials.
|
||||||
|
|
||||||
|
(*) Open file credentials.
|
||||||
|
|
||||||
|
(*) Overriding the VFS's use of credentials.
|
||||||
|
|
||||||
|
|
||||||
|
========
|
||||||
|
OVERVIEW
|
||||||
|
========
|
||||||
|
|
||||||
|
There are several parts to the security check performed by Linux when one
|
||||||
|
object acts upon another:
|
||||||
|
|
||||||
|
(1) Objects.
|
||||||
|
|
||||||
|
Objects are things in the system that may be acted upon directly by
|
||||||
|
userspace programs. Linux has a variety of actionable objects, including:
|
||||||
|
|
||||||
|
- Tasks
|
||||||
|
- Files/inodes
|
||||||
|
- Sockets
|
||||||
|
- Message queues
|
||||||
|
- Shared memory segments
|
||||||
|
- Semaphores
|
||||||
|
- Keys
|
||||||
|
|
||||||
|
As a part of the description of all these objects there is a set of
|
||||||
|
credentials. What's in the set depends on the type of object.
|
||||||
|
|
||||||
|
(2) Object ownership.
|
||||||
|
|
||||||
|
Amongst the credentials of most objects, there will be a subset that
|
||||||
|
indicates the ownership of that object. This is used for resource
|
||||||
|
accounting and limitation (disk quotas and task rlimits for example).
|
||||||
|
|
||||||
|
In a standard UNIX filesystem, for instance, this will be defined by the
|
||||||
|
UID marked on the inode.
|
||||||
|
|
||||||
|
(3) The objective context.
|
||||||
|
|
||||||
|
Also amongst the credentials of those objects, there will be a subset that
|
||||||
|
indicates the 'objective context' of that object. This may or may not be
|
||||||
|
the same set as in (2) - in standard UNIX files, for instance, this is the
|
||||||
|
defined by the UID and the GID marked on the inode.
|
||||||
|
|
||||||
|
The objective context is used as part of the security calculation that is
|
||||||
|
carried out when an object is acted upon.
|
||||||
|
|
||||||
|
(4) Subjects.
|
||||||
|
|
||||||
|
A subject is an object that is acting upon another object.
|
||||||
|
|
||||||
|
Most of the objects in the system are inactive: they don't act on other
|
||||||
|
objects within the system. Processes/tasks are the obvious exception:
|
||||||
|
they do stuff; they access and manipulate things.
|
||||||
|
|
||||||
|
Objects other than tasks may under some circumstances also be subjects.
|
||||||
|
For instance an open file may send SIGIO to a task using the UID and EUID
|
||||||
|
given to it by a task that called fcntl(F_SETOWN) upon it. In this case,
|
||||||
|
the file struct will have a subjective context too.
|
||||||
|
|
||||||
|
(5) The subjective context.
|
||||||
|
|
||||||
|
A subject has an additional interpretation of its credentials. A subset
|
||||||
|
of its credentials forms the 'subjective context'. The subjective context
|
||||||
|
is used as part of the security calculation that is carried out when a
|
||||||
|
subject acts.
|
||||||
|
|
||||||
|
A Linux task, for example, has the FSUID, FSGID and the supplementary
|
||||||
|
group list for when it is acting upon a file - which are quite separate
|
||||||
|
from the real UID and GID that normally form the objective context of the
|
||||||
|
task.
|
||||||
|
|
||||||
|
(6) Actions.
|
||||||
|
|
||||||
|
Linux has a number of actions available that a subject may perform upon an
|
||||||
|
object. The set of actions available depends on the nature of the subject
|
||||||
|
and the object.
|
||||||
|
|
||||||
|
Actions include reading, writing, creating and deleting files; forking or
|
||||||
|
signalling and tracing tasks.
|
||||||
|
|
||||||
|
(7) Rules, access control lists and security calculations.
|
||||||
|
|
||||||
|
When a subject acts upon an object, a security calculation is made. This
|
||||||
|
involves taking the subjective context, the objective context and the
|
||||||
|
action, and searching one or more sets of rules to see whether the subject
|
||||||
|
is granted or denied permission to act in the desired manner on the
|
||||||
|
object, given those contexts.
|
||||||
|
|
||||||
|
There are two main sources of rules:
|
||||||
|
|
||||||
|
(a) Discretionary access control (DAC):
|
||||||
|
|
||||||
|
Sometimes the object will include sets of rules as part of its
|
||||||
|
description. This is an 'Access Control List' or 'ACL'. A Linux
|
||||||
|
file may supply more than one ACL.
|
||||||
|
|
||||||
|
A traditional UNIX file, for example, includes a permissions mask that
|
||||||
|
is an abbreviated ACL with three fixed classes of subject ('user',
|
||||||
|
'group' and 'other'), each of which may be granted certain privileges
|
||||||
|
('read', 'write' and 'execute' - whatever those map to for the object
|
||||||
|
in question). UNIX file permissions do not allow the arbitrary
|
||||||
|
specification of subjects, however, and so are of limited use.
|
||||||
|
|
||||||
|
A Linux file might also sport a POSIX ACL. This is a list of rules
|
||||||
|
that grants various permissions to arbitrary subjects.
|
||||||
|
|
||||||
|
(b) Mandatory access control (MAC):
|
||||||
|
|
||||||
|
The system as a whole may have one or more sets of rules that get
|
||||||
|
applied to all subjects and objects, regardless of their source.
|
||||||
|
SELinux and Smack are examples of this.
|
||||||
|
|
||||||
|
In the case of SELinux and Smack, each object is given a label as part
|
||||||
|
of its credentials. When an action is requested, they take the
|
||||||
|
subject label, the object label and the action and look for a rule
|
||||||
|
that says that this action is either granted or denied.
|
||||||
|
|
||||||
|
|
||||||
|
====================
|
||||||
|
TYPES OF CREDENTIALS
|
||||||
|
====================
|
||||||
|
|
||||||
|
The Linux kernel supports the following types of credentials:
|
||||||
|
|
||||||
|
(1) Traditional UNIX credentials.
|
||||||
|
|
||||||
|
Real User ID
|
||||||
|
Real Group ID
|
||||||
|
|
||||||
|
The UID and GID are carried by most, if not all, Linux objects, even if in
|
||||||
|
some cases it has to be invented (FAT or CIFS files for example, which are
|
||||||
|
derived from Windows). These (mostly) define the objective context of
|
||||||
|
that object, with tasks being slightly different in some cases.
|
||||||
|
|
||||||
|
Effective, Saved and FS User ID
|
||||||
|
Effective, Saved and FS Group ID
|
||||||
|
Supplementary groups
|
||||||
|
|
||||||
|
These are additional credentials used by tasks only. Usually, an
|
||||||
|
EUID/EGID/GROUPS will be used as the subjective context, and real UID/GID
|
||||||
|
will be used as the objective. For tasks, it should be noted that this is
|
||||||
|
not always true.
|
||||||
|
|
||||||
|
(2) Capabilities.
|
||||||
|
|
||||||
|
Set of permitted capabilities
|
||||||
|
Set of inheritable capabilities
|
||||||
|
Set of effective capabilities
|
||||||
|
Capability bounding set
|
||||||
|
|
||||||
|
These are only carried by tasks. They indicate superior capabilities
|
||||||
|
granted piecemeal to a task that an ordinary task wouldn't otherwise have.
|
||||||
|
These are manipulated implicitly by changes to the traditional UNIX
|
||||||
|
credentials, but can also be manipulated directly by the capset() system
|
||||||
|
call.
|
||||||
|
|
||||||
|
The permitted capabilities are those caps that the process might grant
|
||||||
|
itself to its effective or permitted sets through capset(). This
|
||||||
|
inheritable set might also be so constrained.
|
||||||
|
|
||||||
|
The effective capabilities are the ones that a task is actually allowed to
|
||||||
|
make use of itself.
|
||||||
|
|
||||||
|
The inheritable capabilities are the ones that may get passed across
|
||||||
|
execve().
|
||||||
|
|
||||||
|
The bounding set limits the capabilities that may be inherited across
|
||||||
|
execve(), especially when a binary is executed that will execute as UID 0.
|
||||||
|
|
||||||
|
(3) Secure management flags (securebits).
|
||||||
|
|
||||||
|
These are only carried by tasks. These govern the way the above
|
||||||
|
credentials are manipulated and inherited over certain operations such as
|
||||||
|
execve(). They aren't used directly as objective or subjective
|
||||||
|
credentials.
|
||||||
|
|
||||||
|
(4) Keys and keyrings.
|
||||||
|
|
||||||
|
These are only carried by tasks. They carry and cache security tokens
|
||||||
|
that don't fit into the other standard UNIX credentials. They are for
|
||||||
|
making such things as network filesystem keys available to the file
|
||||||
|
accesses performed by processes, without the necessity of ordinary
|
||||||
|
programs having to know about security details involved.
|
||||||
|
|
||||||
|
Keyrings are a special type of key. They carry sets of other keys and can
|
||||||
|
be searched for the desired key. Each process may subscribe to a number
|
||||||
|
of keyrings:
|
||||||
|
|
||||||
|
Per-thread keying
|
||||||
|
Per-process keyring
|
||||||
|
Per-session keyring
|
||||||
|
|
||||||
|
When a process accesses a key, if not already present, it will normally be
|
||||||
|
cached on one of these keyrings for future accesses to find.
|
||||||
|
|
||||||
|
For more information on using keys, see Documentation/keys.txt.
|
||||||
|
|
||||||
|
(5) LSM
|
||||||
|
|
||||||
|
The Linux Security Module allows extra controls to be placed over the
|
||||||
|
operations that a task may do. Currently Linux supports two main
|
||||||
|
alternate LSM options: SELinux and Smack.
|
||||||
|
|
||||||
|
Both work by labelling the objects in a system and then applying sets of
|
||||||
|
rules (policies) that say what operations a task with one label may do to
|
||||||
|
an object with another label.
|
||||||
|
|
||||||
|
(6) AF_KEY
|
||||||
|
|
||||||
|
This is a socket-based approach to credential management for networking
|
||||||
|
stacks [RFC 2367]. It isn't discussed by this document as it doesn't
|
||||||
|
interact directly with task and file credentials; rather it keeps system
|
||||||
|
level credentials.
|
||||||
|
|
||||||
|
|
||||||
|
When a file is opened, part of the opening task's subjective context is
|
||||||
|
recorded in the file struct created. This allows operations using that file
|
||||||
|
struct to use those credentials instead of the subjective context of the task
|
||||||
|
that issued the operation. An example of this would be a file opened on a
|
||||||
|
network filesystem where the credentials of the opened file should be presented
|
||||||
|
to the server, regardless of who is actually doing a read or a write upon it.
|
||||||
|
|
||||||
|
|
||||||
|
=============
|
||||||
|
FILE MARKINGS
|
||||||
|
=============
|
||||||
|
|
||||||
|
Files on disk or obtained over the network may have annotations that form the
|
||||||
|
objective security context of that file. Depending on the type of filesystem,
|
||||||
|
this may include one or more of the following:
|
||||||
|
|
||||||
|
(*) UNIX UID, GID, mode;
|
||||||
|
|
||||||
|
(*) Windows user ID;
|
||||||
|
|
||||||
|
(*) Access control list;
|
||||||
|
|
||||||
|
(*) LSM security label;
|
||||||
|
|
||||||
|
(*) UNIX exec privilege escalation bits (SUID/SGID);
|
||||||
|
|
||||||
|
(*) File capabilities exec privilege escalation bits.
|
||||||
|
|
||||||
|
These are compared to the task's subjective security context, and certain
|
||||||
|
operations allowed or disallowed as a result. In the case of execve(), the
|
||||||
|
privilege escalation bits come into play, and may allow the resulting process
|
||||||
|
extra privileges, based on the annotations on the executable file.
|
||||||
|
|
||||||
|
|
||||||
|
================
|
||||||
|
TASK CREDENTIALS
|
||||||
|
================
|
||||||
|
|
||||||
|
In Linux, all of a task's credentials are held in (uid, gid) or through
|
||||||
|
(groups, keys, LSM security) a refcounted structure of type 'struct cred'.
|
||||||
|
Each task points to its credentials by a pointer called 'cred' in its
|
||||||
|
task_struct.
|
||||||
|
|
||||||
|
Once a set of credentials has been prepared and committed, it may not be
|
||||||
|
changed, barring the following exceptions:
|
||||||
|
|
||||||
|
(1) its reference count may be changed;
|
||||||
|
|
||||||
|
(2) the reference count on the group_info struct it points to may be changed;
|
||||||
|
|
||||||
|
(3) the reference count on the security data it points to may be changed;
|
||||||
|
|
||||||
|
(4) the reference count on any keyrings it points to may be changed;
|
||||||
|
|
||||||
|
(5) any keyrings it points to may be revoked, expired or have their security
|
||||||
|
attributes changed; and
|
||||||
|
|
||||||
|
(6) the contents of any keyrings to which it points may be changed (the whole
|
||||||
|
point of keyrings being a shared set of credentials, modifiable by anyone
|
||||||
|
with appropriate access).
|
||||||
|
|
||||||
|
To alter anything in the cred struct, the copy-and-replace principle must be
|
||||||
|
adhered to. First take a copy, then alter the copy and then use RCU to change
|
||||||
|
the task pointer to make it point to the new copy. There are wrappers to aid
|
||||||
|
with this (see below).
|
||||||
|
|
||||||
|
A task may only alter its _own_ credentials; it is no longer permitted for a
|
||||||
|
task to alter another's credentials. This means the capset() system call is no
|
||||||
|
longer permitted to take any PID other than the one of the current process.
|
||||||
|
Also keyctl_instantiate() and keyctl_negate() functions no longer permit
|
||||||
|
attachment to process-specific keyrings in the requesting process as the
|
||||||
|
instantiating process may need to create them.
|
||||||
|
|
||||||
|
|
||||||
|
IMMUTABLE CREDENTIALS
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
Once a set of credentials has been made public (by calling commit_creds() for
|
||||||
|
example), it must be considered immutable, barring two exceptions:
|
||||||
|
|
||||||
|
(1) The reference count may be altered.
|
||||||
|
|
||||||
|
(2) Whilst the keyring subscriptions of a set of credentials may not be
|
||||||
|
changed, the keyrings subscribed to may have their contents altered.
|
||||||
|
|
||||||
|
To catch accidental credential alteration at compile time, struct task_struct
|
||||||
|
has _const_ pointers to its credential sets, as does struct file. Furthermore,
|
||||||
|
certain functions such as get_cred() and put_cred() operate on const pointers,
|
||||||
|
thus rendering casts unnecessary, but require to temporarily ditch the const
|
||||||
|
qualification to be able to alter the reference count.
|
||||||
|
|
||||||
|
|
||||||
|
ACCESSING TASK CREDENTIALS
|
||||||
|
--------------------------
|
||||||
|
|
||||||
|
A task being able to alter only its own credentials permits the current process
|
||||||
|
to read or replace its own credentials without the need for any form of locking
|
||||||
|
- which simplifies things greatly. It can just call:
|
||||||
|
|
||||||
|
const struct cred *current_cred()
|
||||||
|
|
||||||
|
to get a pointer to its credentials structure, and it doesn't have to release
|
||||||
|
it afterwards.
|
||||||
|
|
||||||
|
There are convenience wrappers for retrieving specific aspects of a task's
|
||||||
|
credentials (the value is simply returned in each case):
|
||||||
|
|
||||||
|
uid_t current_uid(void) Current's real UID
|
||||||
|
gid_t current_gid(void) Current's real GID
|
||||||
|
uid_t current_euid(void) Current's effective UID
|
||||||
|
gid_t current_egid(void) Current's effective GID
|
||||||
|
uid_t current_fsuid(void) Current's file access UID
|
||||||
|
gid_t current_fsgid(void) Current's file access GID
|
||||||
|
kernel_cap_t current_cap(void) Current's effective capabilities
|
||||||
|
void *current_security(void) Current's LSM security pointer
|
||||||
|
struct user_struct *current_user(void) Current's user account
|
||||||
|
|
||||||
|
There are also convenience wrappers for retrieving specific associated pairs of
|
||||||
|
a task's credentials:
|
||||||
|
|
||||||
|
void current_uid_gid(uid_t *, gid_t *);
|
||||||
|
void current_euid_egid(uid_t *, gid_t *);
|
||||||
|
void current_fsuid_fsgid(uid_t *, gid_t *);
|
||||||
|
|
||||||
|
which return these pairs of values through their arguments after retrieving
|
||||||
|
them from the current task's credentials.
|
||||||
|
|
||||||
|
|
||||||
|
In addition, there is a function for obtaining a reference on the current
|
||||||
|
process's current set of credentials:
|
||||||
|
|
||||||
|
const struct cred *get_current_cred(void);
|
||||||
|
|
||||||
|
and functions for getting references to one of the credentials that don't
|
||||||
|
actually live in struct cred:
|
||||||
|
|
||||||
|
struct user_struct *get_current_user(void);
|
||||||
|
struct group_info *get_current_groups(void);
|
||||||
|
|
||||||
|
which get references to the current process's user accounting structure and
|
||||||
|
supplementary groups list respectively.
|
||||||
|
|
||||||
|
Once a reference has been obtained, it must be released with put_cred(),
|
||||||
|
free_uid() or put_group_info() as appropriate.
|
||||||
|
|
||||||
|
|
||||||
|
ACCESSING ANOTHER TASK'S CREDENTIALS
|
||||||
|
------------------------------------
|
||||||
|
|
||||||
|
Whilst a task may access its own credentials without the need for locking, the
|
||||||
|
same is not true of a task wanting to access another task's credentials. It
|
||||||
|
must use the RCU read lock and rcu_dereference().
|
||||||
|
|
||||||
|
The rcu_dereference() is wrapped by:
|
||||||
|
|
||||||
|
const struct cred *__task_cred(struct task_struct *task);
|
||||||
|
|
||||||
|
This should be used inside the RCU read lock, as in the following example:
|
||||||
|
|
||||||
|
void foo(struct task_struct *t, struct foo_data *f)
|
||||||
|
{
|
||||||
|
const struct cred *tcred;
|
||||||
|
...
|
||||||
|
rcu_read_lock();
|
||||||
|
tcred = __task_cred(t);
|
||||||
|
f->uid = tcred->uid;
|
||||||
|
f->gid = tcred->gid;
|
||||||
|
f->groups = get_group_info(tcred->groups);
|
||||||
|
rcu_read_unlock();
|
||||||
|
...
|
||||||
|
}
|
||||||
|
|
||||||
|
A function need not get RCU read lock to use __task_cred() if it is holding a
|
||||||
|
spinlock at the time as this implicitly holds the RCU read lock.
|
||||||
|
|
||||||
|
Should it be necessary to hold another task's credentials for a long period of
|
||||||
|
time, and possibly to sleep whilst doing so, then the caller should get a
|
||||||
|
reference on them using:
|
||||||
|
|
||||||
|
const struct cred *get_task_cred(struct task_struct *task);
|
||||||
|
|
||||||
|
This does all the RCU magic inside of it. The caller must call put_cred() on
|
||||||
|
the credentials so obtained when they're finished with.
|
||||||
|
|
||||||
|
There are a couple of convenience functions to access bits of another task's
|
||||||
|
credentials, hiding the RCU magic from the caller:
|
||||||
|
|
||||||
|
uid_t task_uid(task) Task's real UID
|
||||||
|
uid_t task_euid(task) Task's effective UID
|
||||||
|
|
||||||
|
If the caller is holding a spinlock or the RCU read lock at the time anyway,
|
||||||
|
then:
|
||||||
|
|
||||||
|
__task_cred(task)->uid
|
||||||
|
__task_cred(task)->euid
|
||||||
|
|
||||||
|
should be used instead. Similarly, if multiple aspects of a task's credentials
|
||||||
|
need to be accessed, RCU read lock or a spinlock should be used, __task_cred()
|
||||||
|
called, the result stored in a temporary pointer and then the credential
|
||||||
|
aspects called from that before dropping the lock. This prevents the
|
||||||
|
potentially expensive RCU magic from being invoked multiple times.
|
||||||
|
|
||||||
|
Should some other single aspect of another task's credentials need to be
|
||||||
|
accessed, then this can be used:
|
||||||
|
|
||||||
|
task_cred_xxx(task, member)
|
||||||
|
|
||||||
|
where 'member' is a non-pointer member of the cred struct. For instance:
|
||||||
|
|
||||||
|
uid_t task_cred_xxx(task, suid);
|
||||||
|
|
||||||
|
will retrieve 'struct cred::suid' from the task, doing the appropriate RCU
|
||||||
|
magic. This may not be used for pointer members as what they point to may
|
||||||
|
disappear the moment the RCU read lock is dropped.
|
||||||
|
|
||||||
|
|
||||||
|
ALTERING CREDENTIALS
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
As previously mentioned, a task may only alter its own credentials, and may not
|
||||||
|
alter those of another task. This means that it doesn't need to use any
|
||||||
|
locking to alter its own credentials.
|
||||||
|
|
||||||
|
To alter the current process's credentials, a function should first prepare a
|
||||||
|
new set of credentials by calling:
|
||||||
|
|
||||||
|
struct cred *prepare_creds(void);
|
||||||
|
|
||||||
|
this locks current->cred_replace_mutex and then allocates and constructs a
|
||||||
|
duplicate of the current process's credentials, returning with the mutex still
|
||||||
|
held if successful. It returns NULL if not successful (out of memory).
|
||||||
|
|
||||||
|
The mutex prevents ptrace() from altering the ptrace state of a process whilst
|
||||||
|
security checks on credentials construction and changing is taking place as
|
||||||
|
the ptrace state may alter the outcome, particularly in the case of execve().
|
||||||
|
|
||||||
|
The new credentials set should be altered appropriately, and any security
|
||||||
|
checks and hooks done. Both the current and the proposed sets of credentials
|
||||||
|
are available for this purpose as current_cred() will return the current set
|
||||||
|
still at this point.
|
||||||
|
|
||||||
|
|
||||||
|
When the credential set is ready, it should be committed to the current process
|
||||||
|
by calling:
|
||||||
|
|
||||||
|
int commit_creds(struct cred *new);
|
||||||
|
|
||||||
|
This will alter various aspects of the credentials and the process, giving the
|
||||||
|
LSM a chance to do likewise, then it will use rcu_assign_pointer() to actually
|
||||||
|
commit the new credentials to current->cred, it will release
|
||||||
|
current->cred_replace_mutex to allow ptrace() to take place, and it will notify
|
||||||
|
the scheduler and others of the changes.
|
||||||
|
|
||||||
|
This function is guaranteed to return 0, so that it can be tail-called at the
|
||||||
|
end of such functions as sys_setresuid().
|
||||||
|
|
||||||
|
Note that this function consumes the caller's reference to the new credentials.
|
||||||
|
The caller should _not_ call put_cred() on the new credentials afterwards.
|
||||||
|
|
||||||
|
Furthermore, once this function has been called on a new set of credentials,
|
||||||
|
those credentials may _not_ be changed further.
|
||||||
|
|
||||||
|
|
||||||
|
Should the security checks fail or some other error occur after prepare_creds()
|
||||||
|
has been called, then the following function should be invoked:
|
||||||
|
|
||||||
|
void abort_creds(struct cred *new);
|
||||||
|
|
||||||
|
This releases the lock on current->cred_replace_mutex that prepare_creds() got
|
||||||
|
and then releases the new credentials.
|
||||||
|
|
||||||
|
|
||||||
|
A typical credentials alteration function would look something like this:
|
||||||
|
|
||||||
|
int alter_suid(uid_t suid)
|
||||||
|
{
|
||||||
|
struct cred *new;
|
||||||
|
int ret;
|
||||||
|
|
||||||
|
new = prepare_creds();
|
||||||
|
if (!new)
|
||||||
|
return -ENOMEM;
|
||||||
|
|
||||||
|
new->suid = suid;
|
||||||
|
ret = security_alter_suid(new);
|
||||||
|
if (ret < 0) {
|
||||||
|
abort_creds(new);
|
||||||
|
return ret;
|
||||||
|
}
|
||||||
|
|
||||||
|
return commit_creds(new);
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
|
MANAGING CREDENTIALS
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
There are some functions to help manage credentials:
|
||||||
|
|
||||||
|
(*) void put_cred(const struct cred *cred);
|
||||||
|
|
||||||
|
This releases a reference to the given set of credentials. If the
|
||||||
|
reference count reaches zero, the credentials will be scheduled for
|
||||||
|
destruction by the RCU system.
|
||||||
|
|
||||||
|
(*) const struct cred *get_cred(const struct cred *cred);
|
||||||
|
|
||||||
|
This gets a reference on a live set of credentials, returning a pointer to
|
||||||
|
that set of credentials.
|
||||||
|
|
||||||
|
(*) struct cred *get_new_cred(struct cred *cred);
|
||||||
|
|
||||||
|
This gets a reference on a set of credentials that is under construction
|
||||||
|
and is thus still mutable, returning a pointer to that set of credentials.
|
||||||
|
|
||||||
|
|
||||||
|
=====================
|
||||||
|
OPEN FILE CREDENTIALS
|
||||||
|
=====================
|
||||||
|
|
||||||
|
When a new file is opened, a reference is obtained on the opening task's
|
||||||
|
credentials and this is attached to the file struct as 'f_cred' in place of
|
||||||
|
'f_uid' and 'f_gid'. Code that used to access file->f_uid and file->f_gid
|
||||||
|
should now access file->f_cred->fsuid and file->f_cred->fsgid.
|
||||||
|
|
||||||
|
It is safe to access f_cred without the use of RCU or locking because the
|
||||||
|
pointer will not change over the lifetime of the file struct, and nor will the
|
||||||
|
contents of the cred struct pointed to, barring the exceptions listed above
|
||||||
|
(see the Task Credentials section).
|
||||||
|
|
||||||
|
|
||||||
|
=======================================
|
||||||
|
OVERRIDING THE VFS'S USE OF CREDENTIALS
|
||||||
|
=======================================
|
||||||
|
|
||||||
|
Under some circumstances it is desirable to override the credentials used by
|
||||||
|
the VFS, and that can be done by calling into such as vfs_mkdir() with a
|
||||||
|
different set of credentials. This is done in the following places:
|
||||||
|
|
||||||
|
(*) sys_faccessat().
|
||||||
|
|
||||||
|
(*) do_coredump().
|
||||||
|
|
||||||
|
(*) nfs4recover.c.
|
|
@ -13,9 +13,9 @@
|
||||||
3.6 Constraints
|
3.6 Constraints
|
||||||
3.7 Example
|
3.7 Example
|
||||||
|
|
||||||
4 DRIVER DEVELOPER NOTES
|
4 DMAENGINE DRIVER DEVELOPER NOTES
|
||||||
4.1 Conformance points
|
4.1 Conformance points
|
||||||
4.2 "My application needs finer control of hardware channels"
|
4.2 "My application needs exclusive control of hardware channels"
|
||||||
|
|
||||||
5 SOURCE
|
5 SOURCE
|
||||||
|
|
||||||
|
@ -150,6 +150,7 @@ ops_run_* and ops_complete_* routines in drivers/md/raid5.c for more
|
||||||
implementation examples.
|
implementation examples.
|
||||||
|
|
||||||
4 DRIVER DEVELOPMENT NOTES
|
4 DRIVER DEVELOPMENT NOTES
|
||||||
|
|
||||||
4.1 Conformance points:
|
4.1 Conformance points:
|
||||||
There are a few conformance points required in dmaengine drivers to
|
There are a few conformance points required in dmaengine drivers to
|
||||||
accommodate assumptions made by applications using the async_tx API:
|
accommodate assumptions made by applications using the async_tx API:
|
||||||
|
@ -158,58 +159,49 @@ accommodate assumptions made by applications using the async_tx API:
|
||||||
3/ Use async_tx_run_dependencies() in the descriptor clean up path to
|
3/ Use async_tx_run_dependencies() in the descriptor clean up path to
|
||||||
handle submission of dependent operations
|
handle submission of dependent operations
|
||||||
|
|
||||||
4.2 "My application needs finer control of hardware channels"
|
4.2 "My application needs exclusive control of hardware channels"
|
||||||
This requirement seems to arise from cases where a DMA engine driver is
|
Primarily this requirement arises from cases where a DMA engine driver
|
||||||
trying to support device-to-memory DMA. The dmaengine and async_tx
|
is being used to support device-to-memory operations. A channel that is
|
||||||
implementations were designed for offloading memory-to-memory
|
performing these operations cannot, for many platform specific reasons,
|
||||||
operations; however, there are some capabilities of the dmaengine layer
|
be shared. For these cases the dma_request_channel() interface is
|
||||||
that can be used for platform-specific channel management.
|
provided.
|
||||||
Platform-specific constraints can be handled by registering the
|
|
||||||
application as a 'dma_client' and implementing a 'dma_event_callback' to
|
|
||||||
apply a filter to the available channels in the system. Before showing
|
|
||||||
how to implement a custom dma_event callback some background of
|
|
||||||
dmaengine's client support is required.
|
|
||||||
|
|
||||||
The following routines in dmaengine support multiple clients requesting
|
The interface is:
|
||||||
use of a channel:
|
struct dma_chan *dma_request_channel(dma_cap_mask_t mask,
|
||||||
- dma_async_client_register(struct dma_client *client)
|
dma_filter_fn filter_fn,
|
||||||
- dma_async_client_chan_request(struct dma_client *client)
|
void *filter_param);
|
||||||
|
|
||||||
dma_async_client_register takes a pointer to an initialized dma_client
|
Where dma_filter_fn is defined as:
|
||||||
structure. It expects that the 'event_callback' and 'cap_mask' fields
|
typedef bool (*dma_filter_fn)(struct dma_chan *chan, void *filter_param);
|
||||||
are already initialized.
|
|
||||||
|
|
||||||
dma_async_client_chan_request triggers dmaengine to notify the client of
|
When the optional 'filter_fn' parameter is set to NULL
|
||||||
all channels that satisfy the capability mask. It is up to the client's
|
dma_request_channel simply returns the first channel that satisfies the
|
||||||
event_callback routine to track how many channels the client needs and
|
capability mask. Otherwise, when the mask parameter is insufficient for
|
||||||
how many it is currently using. The dma_event_callback routine returns a
|
specifying the necessary channel, the filter_fn routine can be used to
|
||||||
dma_state_client code to let dmaengine know the status of the
|
disposition the available channels in the system. The filter_fn routine
|
||||||
allocation.
|
is called once for each free channel in the system. Upon seeing a
|
||||||
|
suitable channel filter_fn returns DMA_ACK which flags that channel to
|
||||||
|
be the return value from dma_request_channel. A channel allocated via
|
||||||
|
this interface is exclusive to the caller, until dma_release_channel()
|
||||||
|
is called.
|
||||||
|
|
||||||
Below is the example of how to extend this functionality for
|
The DMA_PRIVATE capability flag is used to tag dma devices that should
|
||||||
platform-specific filtering of the available channels beyond the
|
not be used by the general-purpose allocator. It can be set at
|
||||||
standard capability mask:
|
initialization time if it is known that a channel will always be
|
||||||
|
private. Alternatively, it is set when dma_request_channel() finds an
|
||||||
|
unused "public" channel.
|
||||||
|
|
||||||
static enum dma_state_client
|
A couple caveats to note when implementing a driver and consumer:
|
||||||
my_dma_client_callback(struct dma_client *client,
|
1/ Once a channel has been privately allocated it will no longer be
|
||||||
struct dma_chan *chan, enum dma_state state)
|
considered by the general-purpose allocator even after a call to
|
||||||
{
|
dma_release_channel().
|
||||||
struct dma_device *dma_dev;
|
2/ Since capabilities are specified at the device level a dma_device
|
||||||
struct my_platform_specific_dma *plat_dma_dev;
|
with multiple channels will either have all channels public, or all
|
||||||
|
channels private.
|
||||||
dma_dev = chan->device;
|
|
||||||
plat_dma_dev = container_of(dma_dev,
|
|
||||||
struct my_platform_specific_dma,
|
|
||||||
dma_dev);
|
|
||||||
|
|
||||||
if (!plat_dma_dev->platform_specific_capability)
|
|
||||||
return DMA_DUP;
|
|
||||||
|
|
||||||
. . .
|
|
||||||
}
|
|
||||||
|
|
||||||
5 SOURCE
|
5 SOURCE
|
||||||
include/linux/dmaengine.h: core header file for DMA drivers and clients
|
|
||||||
|
include/linux/dmaengine.h: core header file for DMA drivers and api users
|
||||||
drivers/dma/dmaengine.c: offload engine channel management routines
|
drivers/dma/dmaengine.c: offload engine channel management routines
|
||||||
drivers/dma/: location for offload engine drivers
|
drivers/dma/: location for offload engine drivers
|
||||||
include/linux/async_tx.h: core header file for the async_tx api
|
include/linux/async_tx.h: core header file for the async_tx api
|
||||||
|
|
|
@ -81,8 +81,8 @@ Until this step is completed the driver cannot be unloaded.
|
||||||
Also echoing either mono ,packet or init in to image_type will free up the
|
Also echoing either mono ,packet or init in to image_type will free up the
|
||||||
memory allocated by the driver.
|
memory allocated by the driver.
|
||||||
|
|
||||||
If an user by accident executes steps 1 and 3 above without executing step 2;
|
If a user by accident executes steps 1 and 3 above without executing step 2;
|
||||||
it will make the /sys/class/firmware/dell_rbu/ entries to disappear.
|
it will make the /sys/class/firmware/dell_rbu/ entries disappear.
|
||||||
The entries can be recreated by doing the following
|
The entries can be recreated by doing the following
|
||||||
echo init > /sys/devices/platform/dell_rbu/image_type
|
echo init > /sys/devices/platform/dell_rbu/image_type
|
||||||
NOTE: echoing init in image_type does not change it original value.
|
NOTE: echoing init in image_type does not change it original value.
|
||||||
|
|
|
@ -380,5 +380,5 @@ This will help you to be sure that you have found all in-tree uses of that
|
||||||
interface. It will also alert developers of out-of-tree code that there is
|
interface. It will also alert developers of out-of-tree code that there is
|
||||||
a change that they need to respond to. Supporting out-of-tree code is not
|
a change that they need to respond to. Supporting out-of-tree code is not
|
||||||
something that kernel developers need to be worried about, but we also do
|
something that kernel developers need to be worried about, but we also do
|
||||||
not have to make life harder for out-of-tree developers than it it needs to
|
not have to make life harder for out-of-tree developers than it needs to
|
||||||
be.
|
be.
|
||||||
|
|
|
@ -0,0 +1 @@
|
||||||
|
See Documentation/crypto/async-tx-api.txt
|
|
@ -0,0 +1,69 @@
|
||||||
|
How to set up the Technisat devices
|
||||||
|
===================================
|
||||||
|
|
||||||
|
1) Find out what device you have
|
||||||
|
================================
|
||||||
|
|
||||||
|
First start your linux box with a shipped kernel:
|
||||||
|
lspci -vvv for a PCI device (lsusb -vvv for an USB device) will show you for example:
|
||||||
|
02:0b.0 Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02)
|
||||||
|
|
||||||
|
dmesg | grep frontend may show you for example:
|
||||||
|
DVB: registering frontend 0 (Conexant CX24123/CX24109)...
|
||||||
|
|
||||||
|
2) Kernel compilation:
|
||||||
|
======================
|
||||||
|
|
||||||
|
If the Technisat is the only TV device in your box get rid of unnecessary modules and check this one:
|
||||||
|
"Multimedia devices" => "Customise analog and hybrid tuner modules to build"
|
||||||
|
In this directory uncheck every driver which is activated there.
|
||||||
|
|
||||||
|
Then please activate:
|
||||||
|
2a) Main module part:
|
||||||
|
|
||||||
|
a.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters"
|
||||||
|
b.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC PCI" in case of a PCI card OR
|
||||||
|
c.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Technisat/B2C2 Air/Sky/Cable2PC USB" in case of an USB 1.1 adapter
|
||||||
|
d.)"Multimedia devices" => "DVB/ATSC adapters" => "Technisat/B2C2 FlexcopII(b) and FlexCopIII adapters" => "Enable debug for the B2C2 FlexCop drivers"
|
||||||
|
Notice: d.) is helpful for troubleshooting
|
||||||
|
|
||||||
|
2b) Frontend module part:
|
||||||
|
|
||||||
|
1.) Revision 2.3:
|
||||||
|
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||||
|
b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink VP310/MT312/ZL10313 based"
|
||||||
|
|
||||||
|
2.) Revision 2.6:
|
||||||
|
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||||
|
b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0299 based"
|
||||||
|
|
||||||
|
3.) Revision 2.7:
|
||||||
|
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||||
|
b.)"Multimedia devices" => "Customise DVB frontends" => "Samsung S5H1420 based"
|
||||||
|
c.)"Multimedia devices" => "Customise DVB frontends" => "Integrant ITD1000 Zero IF tuner for DVB-S/DSS"
|
||||||
|
d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller"
|
||||||
|
|
||||||
|
4.) Revision 2.8:
|
||||||
|
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||||
|
b.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24113/CX24128 tuner for DVB-S/DSS"
|
||||||
|
c.)"Multimedia devices" => "Customise DVB frontends" => "Conexant CX24123 based"
|
||||||
|
d.)"Multimedia devices" => "Customise DVB frontends" => "ISL6421 SEC controller"
|
||||||
|
|
||||||
|
5.) DVB-T card:
|
||||||
|
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||||
|
b.)"Multimedia devices" => "Customise DVB frontends" => "Zarlink MT352 based"
|
||||||
|
|
||||||
|
6.) DVB-C card:
|
||||||
|
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||||
|
b.)"Multimedia devices" => "Customise DVB frontends" => "ST STV0297 based"
|
||||||
|
|
||||||
|
7.) ATSC card 1st generation:
|
||||||
|
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||||
|
b.)"Multimedia devices" => "Customise DVB frontends" => "Broadcom BCM3510"
|
||||||
|
|
||||||
|
8.) ATSC card 2nd generation:
|
||||||
|
a.)"Multimedia devices" => "Customise DVB frontends" => "Customise the frontend modules to build"
|
||||||
|
b.)"Multimedia devices" => "Customise DVB frontends" => "NxtWave Communications NXT2002/NXT2004 based"
|
||||||
|
c.)"Multimedia devices" => "Customise DVB frontends" => "LG Electronics LGDT3302/LGDT3303 based"
|
||||||
|
|
||||||
|
Author: Uwe Bugla <uwe.bugla@gmx.de> December 2008
|
|
@ -5,9 +5,13 @@ The driver supports the following options, either via
|
||||||
options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in.
|
options=<OPTIONS> when modular or video=pxafb:<OPTIONS> when built in.
|
||||||
|
|
||||||
For example:
|
For example:
|
||||||
modprobe pxafb options=mode:640x480-8,passive
|
modprobe pxafb options=vmem:2M,mode:640x480-8,passive
|
||||||
or on the kernel command line
|
or on the kernel command line
|
||||||
video=pxafb:mode:640x480-8,passive
|
video=pxafb:vmem:2M,mode:640x480-8,passive
|
||||||
|
|
||||||
|
vmem: VIDEO_MEM_SIZE
|
||||||
|
Amount of video memory to allocate (can be suffixed with K or M
|
||||||
|
for kilobytes or megabytes)
|
||||||
|
|
||||||
mode:XRESxYRES[-BPP]
|
mode:XRESxYRES[-BPP]
|
||||||
XRES == LCCR1_PPL + 1
|
XRES == LCCR1_PPL + 1
|
||||||
|
@ -52,3 +56,87 @@ outputen:POLARITY
|
||||||
pixclockpol:POLARITY
|
pixclockpol:POLARITY
|
||||||
pixel clock polarity
|
pixel clock polarity
|
||||||
0 => falling edge, 1 => rising edge
|
0 => falling edge, 1 => rising edge
|
||||||
|
|
||||||
|
|
||||||
|
Overlay Support for PXA27x and later LCD controllers
|
||||||
|
====================================================
|
||||||
|
|
||||||
|
PXA27x and later processors support overlay1 and overlay2 on-top of the
|
||||||
|
base framebuffer (although under-neath the base is also possible). They
|
||||||
|
support palette and no-palette RGB formats, as well as YUV formats (only
|
||||||
|
available on overlay2). These overlays have dedicated DMA channels and
|
||||||
|
behave in a similar way as a framebuffer.
|
||||||
|
|
||||||
|
However, there are some differences between these overlay framebuffers
|
||||||
|
and normal framebuffers, as listed below:
|
||||||
|
|
||||||
|
1. overlay can start at a 32-bit word aligned position within the base
|
||||||
|
framebuffer, which means they have a start (x, y). This information
|
||||||
|
is encoded into var->nonstd (no, var->xoffset and var->yoffset are
|
||||||
|
not for such purpose).
|
||||||
|
|
||||||
|
2. overlay framebuffer is allocated dynamically according to specified
|
||||||
|
'struct fb_var_screeninfo', the amount is decided by:
|
||||||
|
|
||||||
|
var->xres_virtual * var->yres_virtual * bpp
|
||||||
|
|
||||||
|
bpp = 16 -- for RGB565 or RGBT555
|
||||||
|
= 24 -- for YUV444 packed
|
||||||
|
= 24 -- for YUV444 planar
|
||||||
|
= 16 -- for YUV422 planar (1 pixel = 1 Y + 1/2 Cb + 1/2 Cr)
|
||||||
|
= 12 -- for YUV420 planar (1 pixel = 1 Y + 1/4 Cb + 1/4 Cr)
|
||||||
|
|
||||||
|
NOTE:
|
||||||
|
|
||||||
|
a. overlay does not support panning in x-direction, thus
|
||||||
|
var->xres_virtual will always be equal to var->xres
|
||||||
|
|
||||||
|
b. line length of overlay(s) must be on a 32-bit word boundary,
|
||||||
|
for YUV planar modes, it is a requirement for the component
|
||||||
|
with minimum bits per pixel, e.g. for YUV420, Cr component
|
||||||
|
for one pixel is actually 2-bits, it means the line length
|
||||||
|
should be a multiple of 16-pixels
|
||||||
|
|
||||||
|
c. starting horizontal position (XPOS) should start on a 32-bit
|
||||||
|
word boundary, otherwise the fb_check_var() will just fail.
|
||||||
|
|
||||||
|
d. the rectangle of the overlay should be within the base plane,
|
||||||
|
otherwise fail
|
||||||
|
|
||||||
|
Applications should follow the sequence below to operate an overlay
|
||||||
|
framebuffer:
|
||||||
|
|
||||||
|
a. open("/dev/fb[1-2]", ...)
|
||||||
|
b. ioctl(fd, FBIOGET_VSCREENINFO, ...)
|
||||||
|
c. modify 'var' with desired parameters:
|
||||||
|
1) var->xres and var->yres
|
||||||
|
2) larger var->yres_virtual if more memory is required,
|
||||||
|
usually for double-buffering
|
||||||
|
3) var->nonstd for starting (x, y) and color format
|
||||||
|
4) var->{red, green, blue, transp} if RGB mode is to be used
|
||||||
|
d. ioctl(fd, FBIOPUT_VSCREENINFO, ...)
|
||||||
|
e. ioctl(fd, FBIOGET_FSCREENINFO, ...)
|
||||||
|
f. mmap
|
||||||
|
g. ...
|
||||||
|
|
||||||
|
3. for YUV planar formats, these are actually not supported within the
|
||||||
|
framebuffer framework, application has to take care of the offsets
|
||||||
|
and lengths of each component within the framebuffer.
|
||||||
|
|
||||||
|
4. var->nonstd is used to pass starting (x, y) position and color format,
|
||||||
|
the detailed bit fields are shown below:
|
||||||
|
|
||||||
|
31 23 20 10 0
|
||||||
|
+-----------------+---+----------+----------+
|
||||||
|
| ... unused ... |FOR| XPOS | YPOS |
|
||||||
|
+-----------------+---+----------+----------+
|
||||||
|
|
||||||
|
FOR - color format, as defined by OVERLAY_FORMAT_* in pxafb.h
|
||||||
|
0 - RGB
|
||||||
|
1 - YUV444 PACKED
|
||||||
|
2 - YUV444 PLANAR
|
||||||
|
3 - YUV422 PLANAR
|
||||||
|
4 - YUR420 PLANAR
|
||||||
|
|
||||||
|
XPOS - starting horizontal position
|
||||||
|
YPOS - starting vertical position
|
||||||
|
|
|
@ -120,13 +120,6 @@ Who: Christoph Hellwig <hch@lst.de>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
What: eepro100 network driver
|
|
||||||
When: January 2007
|
|
||||||
Why: replaced by the e100 driver
|
|
||||||
Who: Adrian Bunk <bunk@stusta.de>
|
|
||||||
|
|
||||||
---------------------------
|
|
||||||
|
|
||||||
What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
|
What: Unused EXPORT_SYMBOL/EXPORT_SYMBOL_GPL exports
|
||||||
(temporary transition config option provided until then)
|
(temporary transition config option provided until then)
|
||||||
The transition config option will also be removed at the same time.
|
The transition config option will also be removed at the same time.
|
||||||
|
@ -244,18 +237,6 @@ Who: Michael Buesch <mb@bu3sch.de>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
What: init_mm export
|
|
||||||
When: 2.6.26
|
|
||||||
Why: Not used in-tree. The current out-of-tree users used it to
|
|
||||||
work around problems in the CPA code which should be resolved
|
|
||||||
by now. One usecase was described to provide verification code
|
|
||||||
of the CPA operation. That's a good idea in general, but such
|
|
||||||
code / infrastructure should be in the kernel and not in some
|
|
||||||
out-of-tree driver.
|
|
||||||
Who: Thomas Gleixner <tglx@linutronix.de>
|
|
||||||
|
|
||||||
----------------------------
|
|
||||||
|
|
||||||
What: usedac i386 kernel parameter
|
What: usedac i386 kernel parameter
|
||||||
When: 2.6.27
|
When: 2.6.27
|
||||||
Why: replaced by allowdac and no dac combination
|
Why: replaced by allowdac and no dac combination
|
||||||
|
@ -329,17 +310,28 @@ Who: Krzysztof Piotr Oledzki <ole@ans.pl>
|
||||||
|
|
||||||
---------------------------
|
---------------------------
|
||||||
|
|
||||||
What: ide-scsi (BLK_DEV_IDESCSI)
|
|
||||||
When: 2.6.29
|
|
||||||
Why: The 2.6 kernel supports direct writing to ide CD drives, which
|
|
||||||
eliminates the need for ide-scsi. The new method is more
|
|
||||||
efficient in every way.
|
|
||||||
Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
|
|
||||||
|
|
||||||
---------------------------
|
|
||||||
|
|
||||||
What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client()
|
What: i2c_attach_client(), i2c_detach_client(), i2c_driver->detach_client()
|
||||||
When: 2.6.29 (ideally) or 2.6.30 (more likely)
|
When: 2.6.29 (ideally) or 2.6.30 (more likely)
|
||||||
Why: Deprecated by the new (standard) device driver binding model. Use
|
Why: Deprecated by the new (standard) device driver binding model. Use
|
||||||
i2c_driver->probe() and ->remove() instead.
|
i2c_driver->probe() and ->remove() instead.
|
||||||
Who: Jean Delvare <khali@linux-fr.org>
|
Who: Jean Delvare <khali@linux-fr.org>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
What: fscher and fscpos drivers
|
||||||
|
When: June 2009
|
||||||
|
Why: Deprecated by the new fschmd driver.
|
||||||
|
Who: Hans de Goede <hdegoede@redhat.com>
|
||||||
|
Jean Delvare <khali@linux-fr.org>
|
||||||
|
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
What: SELinux "compat_net" functionality
|
||||||
|
When: 2.6.30 at the earliest
|
||||||
|
Why: In 2.6.18 the Secmark concept was introduced to replace the "compat_net"
|
||||||
|
network access control functionality of SELinux. Secmark offers both
|
||||||
|
better performance and greater flexibility than the "compat_net"
|
||||||
|
mechanism. Now that the major Linux distributions have moved to
|
||||||
|
Secmark, it is time to deprecate the older mechanism and start the
|
||||||
|
process of removing the old code.
|
||||||
|
Who: Paul Moore <paul.moore@hp.com>
|
||||||
|
|
|
@ -97,8 +97,8 @@ prototypes:
|
||||||
void (*put_super) (struct super_block *);
|
void (*put_super) (struct super_block *);
|
||||||
void (*write_super) (struct super_block *);
|
void (*write_super) (struct super_block *);
|
||||||
int (*sync_fs)(struct super_block *sb, int wait);
|
int (*sync_fs)(struct super_block *sb, int wait);
|
||||||
void (*write_super_lockfs) (struct super_block *);
|
int (*freeze_fs) (struct super_block *);
|
||||||
void (*unlockfs) (struct super_block *);
|
int (*unfreeze_fs) (struct super_block *);
|
||||||
int (*statfs) (struct dentry *, struct kstatfs *);
|
int (*statfs) (struct dentry *, struct kstatfs *);
|
||||||
int (*remount_fs) (struct super_block *, int *, char *);
|
int (*remount_fs) (struct super_block *, int *, char *);
|
||||||
void (*clear_inode) (struct inode *);
|
void (*clear_inode) (struct inode *);
|
||||||
|
@ -119,8 +119,8 @@ delete_inode: no
|
||||||
put_super: yes yes no
|
put_super: yes yes no
|
||||||
write_super: no yes read
|
write_super: no yes read
|
||||||
sync_fs: no no read
|
sync_fs: no no read
|
||||||
write_super_lockfs: ?
|
freeze_fs: ?
|
||||||
unlockfs: ?
|
unfreeze_fs: ?
|
||||||
statfs: no no no
|
statfs: no no no
|
||||||
remount_fs: yes yes maybe (see below)
|
remount_fs: yes yes maybe (see below)
|
||||||
clear_inode: no
|
clear_inode: no
|
||||||
|
@ -394,11 +394,10 @@ prototypes:
|
||||||
unsigned long (*get_unmapped_area)(struct file *, unsigned long,
|
unsigned long (*get_unmapped_area)(struct file *, unsigned long,
|
||||||
unsigned long, unsigned long, unsigned long);
|
unsigned long, unsigned long, unsigned long);
|
||||||
int (*check_flags)(int);
|
int (*check_flags)(int);
|
||||||
int (*dir_notify)(struct file *, unsigned long);
|
|
||||||
};
|
};
|
||||||
|
|
||||||
locking rules:
|
locking rules:
|
||||||
All except ->poll() may block.
|
All may block.
|
||||||
BKL
|
BKL
|
||||||
llseek: no (see below)
|
llseek: no (see below)
|
||||||
read: no
|
read: no
|
||||||
|
@ -424,7 +423,6 @@ sendfile: no
|
||||||
sendpage: no
|
sendpage: no
|
||||||
get_unmapped_area: no
|
get_unmapped_area: no
|
||||||
check_flags: no
|
check_flags: no
|
||||||
dir_notify: no
|
|
||||||
|
|
||||||
->llseek() locking has moved from llseek to the individual llseek
|
->llseek() locking has moved from llseek to the individual llseek
|
||||||
implementations. If your fs is not using generic_file_llseek, you
|
implementations. If your fs is not using generic_file_llseek, you
|
||||||
|
|
|
@ -0,0 +1,91 @@
|
||||||
|
|
||||||
|
BTRFS
|
||||||
|
=====
|
||||||
|
|
||||||
|
Btrfs is a new copy on write filesystem for Linux aimed at
|
||||||
|
implementing advanced features while focusing on fault tolerance,
|
||||||
|
repair and easy administration. Initially developed by Oracle, Btrfs
|
||||||
|
is licensed under the GPL and open for contribution from anyone.
|
||||||
|
|
||||||
|
Linux has a wealth of filesystems to choose from, but we are facing a
|
||||||
|
number of challenges with scaling to the large storage subsystems that
|
||||||
|
are becoming common in today's data centers. Filesystems need to scale
|
||||||
|
in their ability to address and manage large storage, and also in
|
||||||
|
their ability to detect, repair and tolerate errors in the data stored
|
||||||
|
on disk. Btrfs is under heavy development, and is not suitable for
|
||||||
|
any uses other than benchmarking and review. The Btrfs disk format is
|
||||||
|
not yet finalized.
|
||||||
|
|
||||||
|
The main Btrfs features include:
|
||||||
|
|
||||||
|
* Extent based file storage (2^64 max file size)
|
||||||
|
* Space efficient packing of small files
|
||||||
|
* Space efficient indexed directories
|
||||||
|
* Dynamic inode allocation
|
||||||
|
* Writable snapshots
|
||||||
|
* Subvolumes (separate internal filesystem roots)
|
||||||
|
* Object level mirroring and striping
|
||||||
|
* Checksums on data and metadata (multiple algorithms available)
|
||||||
|
* Compression
|
||||||
|
* Integrated multiple device support, with several raid algorithms
|
||||||
|
* Online filesystem check (not yet implemented)
|
||||||
|
* Very fast offline filesystem check
|
||||||
|
* Efficient incremental backup and FS mirroring (not yet implemented)
|
||||||
|
* Online filesystem defragmentation
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
MAILING LIST
|
||||||
|
============
|
||||||
|
|
||||||
|
There is a Btrfs mailing list hosted on vger.kernel.org. You can
|
||||||
|
find details on how to subscribe here:
|
||||||
|
|
||||||
|
http://vger.kernel.org/vger-lists.html#linux-btrfs
|
||||||
|
|
||||||
|
Mailing list archives are available from gmane:
|
||||||
|
|
||||||
|
http://dir.gmane.org/gmane.comp.file-systems.btrfs
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
IRC
|
||||||
|
===
|
||||||
|
|
||||||
|
Discussion of Btrfs also occurs on the #btrfs channel of the Freenode
|
||||||
|
IRC network.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
UTILITIES
|
||||||
|
=========
|
||||||
|
|
||||||
|
Userspace tools for creating and manipulating Btrfs file systems are
|
||||||
|
available from the git repository at the following location:
|
||||||
|
|
||||||
|
http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs-unstable.git
|
||||||
|
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git
|
||||||
|
|
||||||
|
These include the following tools:
|
||||||
|
|
||||||
|
mkfs.btrfs: create a filesystem
|
||||||
|
|
||||||
|
btrfsctl: control program to create snapshots and subvolumes:
|
||||||
|
|
||||||
|
mount /dev/sda2 /mnt
|
||||||
|
btrfsctl -s new_subvol_name /mnt
|
||||||
|
btrfsctl -s snapshot_of_default /mnt/default
|
||||||
|
btrfsctl -s snapshot_of_new_subvol /mnt/new_subvol_name
|
||||||
|
btrfsctl -s snapshot_of_a_snapshot /mnt/snapshot_of_new_subvol
|
||||||
|
ls /mnt
|
||||||
|
default snapshot_of_a_snapshot snapshot_of_new_subvol
|
||||||
|
new_subvol_name snapshot_of_default
|
||||||
|
|
||||||
|
Snapshots and subvolumes cannot be deleted right now, but you can
|
||||||
|
rm -rf all the files and directories inside them.
|
||||||
|
|
||||||
|
btrfsck: do a limited check of the FS extent trees.
|
||||||
|
|
||||||
|
btrfs-debug-tree: print all of the FS metadata in text form. Example:
|
||||||
|
|
||||||
|
btrfs-debug-tree /dev/sda2 >& big_output_file
|
|
@ -0,0 +1,132 @@
|
||||||
|
|
||||||
|
To support containers, we now allow multiple instances of devpts filesystem,
|
||||||
|
such that indices of ptys allocated in one instance are independent of indices
|
||||||
|
allocated in other instances of devpts.
|
||||||
|
|
||||||
|
To preserve backward compatibility, this support for multiple instances is
|
||||||
|
enabled only if:
|
||||||
|
|
||||||
|
- CONFIG_DEVPTS_MULTIPLE_INSTANCES=y, and
|
||||||
|
- '-o newinstance' mount option is specified while mounting devpts
|
||||||
|
|
||||||
|
IOW, devpts now supports both single-instance and multi-instance semantics.
|
||||||
|
|
||||||
|
If CONFIG_DEVPTS_MULTIPLE_INSTANCES=n, there is no change in behavior and
|
||||||
|
this referred to as the "legacy" mode. In this mode, the new mount options
|
||||||
|
(-o newinstance and -o ptmxmode) will be ignored with a 'bogus option' message
|
||||||
|
on console.
|
||||||
|
|
||||||
|
If CONFIG_DEVPTS_MULTIPLE_INSTANCES=y and devpts is mounted without the
|
||||||
|
'newinstance' option (as in current start-up scripts) the new mount binds
|
||||||
|
to the initial kernel mount of devpts. This mode is referred to as the
|
||||||
|
'single-instance' mode and the current, single-instance semantics are
|
||||||
|
preserved, i.e PTYs are common across the system.
|
||||||
|
|
||||||
|
The only difference between this single-instance mode and the legacy mode
|
||||||
|
is the presence of new, '/dev/pts/ptmx' node with permissions 0000, which
|
||||||
|
can safely be ignored.
|
||||||
|
|
||||||
|
If CONFIG_DEVPTS_MULTIPLE_INSTANCES=y and 'newinstance' option is specified,
|
||||||
|
the mount is considered to be in the multi-instance mode and a new instance
|
||||||
|
of the devpts fs is created. Any ptys created in this instance are independent
|
||||||
|
of ptys in other instances of devpts. Like in the single-instance mode, the
|
||||||
|
/dev/pts/ptmx node is present. To effectively use the multi-instance mode,
|
||||||
|
open of /dev/ptmx must be a redirected to '/dev/pts/ptmx' using a symlink or
|
||||||
|
bind-mount.
|
||||||
|
|
||||||
|
Eg: A container startup script could do the following:
|
||||||
|
|
||||||
|
$ chmod 0666 /dev/pts/ptmx
|
||||||
|
$ rm /dev/ptmx
|
||||||
|
$ ln -s pts/ptmx /dev/ptmx
|
||||||
|
$ ns_exec -cm /bin/bash
|
||||||
|
|
||||||
|
# We are now in new container
|
||||||
|
|
||||||
|
$ umount /dev/pts
|
||||||
|
$ mount -t devpts -o newinstance lxcpts /dev/pts
|
||||||
|
$ sshd -p 1234
|
||||||
|
|
||||||
|
where 'ns_exec -cm /bin/bash' calls clone() with CLONE_NEWNS flag and execs
|
||||||
|
/bin/bash in the child process. A pty created by the sshd is not visible in
|
||||||
|
the original mount of /dev/pts.
|
||||||
|
|
||||||
|
User-space changes
|
||||||
|
------------------
|
||||||
|
|
||||||
|
In multi-instance mode (i.e '-o newinstance' mount option is specified at least
|
||||||
|
once), following user-space issues should be noted.
|
||||||
|
|
||||||
|
1. If -o newinstance mount option is never used, /dev/pts/ptmx can be ignored
|
||||||
|
and no change is needed to system-startup scripts.
|
||||||
|
|
||||||
|
2. To effectively use multi-instance mode (i.e -o newinstance is specified)
|
||||||
|
administrators or startup scripts should "redirect" open of /dev/ptmx to
|
||||||
|
/dev/pts/ptmx using either a bind mount or symlink.
|
||||||
|
|
||||||
|
$ mount -t devpts -o newinstance devpts /dev/pts
|
||||||
|
|
||||||
|
followed by either
|
||||||
|
|
||||||
|
$ rm /dev/ptmx
|
||||||
|
$ ln -s pts/ptmx /dev/ptmx
|
||||||
|
$ chmod 666 /dev/pts/ptmx
|
||||||
|
or
|
||||||
|
$ mount -o bind /dev/pts/ptmx /dev/ptmx
|
||||||
|
|
||||||
|
3. The '/dev/ptmx -> pts/ptmx' symlink is the preferred method since it
|
||||||
|
enables better error-reporting and treats both single-instance and
|
||||||
|
multi-instance mounts similarly.
|
||||||
|
|
||||||
|
But this method requires that system-startup scripts set the mode of
|
||||||
|
/dev/pts/ptmx correctly (default mode is 0000). The scripts can set the
|
||||||
|
mode by, either
|
||||||
|
|
||||||
|
- adding ptmxmode mount option to devpts entry in /etc/fstab, or
|
||||||
|
- using 'chmod 0666 /dev/pts/ptmx'
|
||||||
|
|
||||||
|
4. If multi-instance mode mount is needed for containers, but the system
|
||||||
|
startup scripts have not yet been updated, container-startup scripts
|
||||||
|
should bind mount /dev/ptmx to /dev/pts/ptmx to avoid breaking single-
|
||||||
|
instance mounts.
|
||||||
|
|
||||||
|
Or, in general, container-startup scripts should use:
|
||||||
|
|
||||||
|
mount -t devpts -o newinstance -o ptmxmode=0666 devpts /dev/pts
|
||||||
|
if [ ! -L /dev/ptmx ]; then
|
||||||
|
mount -o bind /dev/pts/ptmx /dev/ptmx
|
||||||
|
fi
|
||||||
|
|
||||||
|
When all devpts mounts are multi-instance, /dev/ptmx can permanently be
|
||||||
|
a symlink to pts/ptmx and the bind mount can be ignored.
|
||||||
|
|
||||||
|
5. A multi-instance mount that is not accompanied by the /dev/ptmx to
|
||||||
|
/dev/pts/ptmx redirection would result in an unusable/unreachable pty.
|
||||||
|
|
||||||
|
mount -t devpts -o newinstance lxcpts /dev/pts
|
||||||
|
|
||||||
|
immediately followed by:
|
||||||
|
|
||||||
|
open("/dev/ptmx")
|
||||||
|
|
||||||
|
would create a pty, say /dev/pts/7, in the initial kernel mount.
|
||||||
|
But /dev/pts/7 would be invisible in the new mount.
|
||||||
|
|
||||||
|
6. The permissions for /dev/pts/ptmx node should be specified when mounting
|
||||||
|
/dev/pts, using the '-o ptmxmode=%o' mount option (default is 0000).
|
||||||
|
|
||||||
|
mount -t devpts -o newinstance -o ptmxmode=0644 devpts /dev/pts
|
||||||
|
|
||||||
|
The permissions can be later be changed as usual with 'chmod'.
|
||||||
|
|
||||||
|
chmod 666 /dev/pts/ptmx
|
||||||
|
|
||||||
|
7. A mount of devpts without the 'newinstance' option results in binding to
|
||||||
|
initial kernel mount. This behavior while preserving legacy semantics,
|
||||||
|
does not provide strict isolation in a container environment. i.e by
|
||||||
|
mounting devpts without the 'newinstance' option, a container could
|
||||||
|
get visibility into the 'host' or root container's devpts.
|
||||||
|
|
||||||
|
To workaround this and have strict isolation, all mounts of devpts,
|
||||||
|
including the mount in the root container, should use the newinstance
|
||||||
|
option.
|
|
@ -58,13 +58,22 @@ Note: More extensive information for getting started with ext4 can be
|
||||||
|
|
||||||
# mount -t ext4 /dev/hda1 /wherever
|
# mount -t ext4 /dev/hda1 /wherever
|
||||||
|
|
||||||
- When comparing performance with other filesystems, remember that
|
- When comparing performance with other filesystems, it's always
|
||||||
ext3/4 by default offers higher data integrity guarantees than most.
|
important to try multiple workloads; very often a subtle change in a
|
||||||
So when comparing with a metadata-only journalling filesystem, such
|
workload parameter can completely change the ranking of which
|
||||||
as ext3, use `mount -o data=writeback'. And you might as well use
|
filesystems do well compared to others. When comparing versus ext3,
|
||||||
`mount -o nobh' too along with it. Making the journal larger than
|
note that ext4 enables write barriers by default, while ext3 does
|
||||||
the mke2fs default often helps performance with metadata-intensive
|
not enable write barriers by default. So it is useful to use
|
||||||
workloads.
|
explicitly specify whether barriers are enabled or not when via the
|
||||||
|
'-o barriers=[0|1]' mount option for both ext3 and ext4 filesystems
|
||||||
|
for a fair comparison. When tuning ext3 for best benchmark numbers,
|
||||||
|
it is often worthwhile to try changing the data journaling mode; '-o
|
||||||
|
data=writeback,nobh' can be faster for some workloads. (Note
|
||||||
|
however that running mounted with data=writeback can potentially
|
||||||
|
leave stale data exposed in recently written files in case of an
|
||||||
|
unclean shutdown, which could be a security exposure in some
|
||||||
|
situations.) Configuring the filesystem with a large journal can
|
||||||
|
also be helpful for metadata-intensive workloads.
|
||||||
|
|
||||||
2. Features
|
2. Features
|
||||||
===========
|
===========
|
||||||
|
@ -74,7 +83,7 @@ Note: More extensive information for getting started with ext4 can be
|
||||||
* ability to use filesystems > 16TB (e2fsprogs support not available yet)
|
* ability to use filesystems > 16TB (e2fsprogs support not available yet)
|
||||||
* extent format reduces metadata overhead (RAM, IO for access, transactions)
|
* extent format reduces metadata overhead (RAM, IO for access, transactions)
|
||||||
* extent format more robust in face of on-disk corruption due to magics,
|
* extent format more robust in face of on-disk corruption due to magics,
|
||||||
* internal redunancy in tree
|
* internal redundancy in tree
|
||||||
* improved file allocation (multi-block alloc)
|
* improved file allocation (multi-block alloc)
|
||||||
* fix 32000 subdirectory limit
|
* fix 32000 subdirectory limit
|
||||||
* nsec timestamps for mtime, atime, ctime, create time
|
* nsec timestamps for mtime, atime, ctime, create time
|
||||||
|
@ -116,10 +125,11 @@ grouping of bitmaps and inode tables. Some test results available here:
|
||||||
When mounting an ext4 filesystem, the following option are accepted:
|
When mounting an ext4 filesystem, the following option are accepted:
|
||||||
(*) == default
|
(*) == default
|
||||||
|
|
||||||
extents (*) ext4 will use extents to address file data. The
|
ro Mount filesystem read only. Note that ext4 will
|
||||||
file system will no longer be mountable by ext3.
|
replay the journal (and thus write to the
|
||||||
|
partition) even when mounted "read only". The
|
||||||
noextents ext4 will not use extents for newly created files
|
mount options "ro,noload" can be used to prevent
|
||||||
|
writes to the filesystem.
|
||||||
|
|
||||||
journal_checksum Enable checksumming of the journal transactions.
|
journal_checksum Enable checksumming of the journal transactions.
|
||||||
This will allow the recovery code in e2fsck and the
|
This will allow the recovery code in e2fsck and the
|
||||||
|
@ -134,17 +144,17 @@ journal_async_commit Commit block can be written to disk without waiting
|
||||||
journal=update Update the ext4 file system's journal to the current
|
journal=update Update the ext4 file system's journal to the current
|
||||||
format.
|
format.
|
||||||
|
|
||||||
journal=inum When a journal already exists, this option is ignored.
|
|
||||||
Otherwise, it specifies the number of the inode which
|
|
||||||
will represent the ext4 file system's journal file.
|
|
||||||
|
|
||||||
journal_dev=devnum When the external journal device's major/minor numbers
|
journal_dev=devnum When the external journal device's major/minor numbers
|
||||||
have changed, this option allows the user to specify
|
have changed, this option allows the user to specify
|
||||||
the new journal location. The journal device is
|
the new journal location. The journal device is
|
||||||
identified through its new major/minor numbers encoded
|
identified through its new major/minor numbers encoded
|
||||||
in devnum.
|
in devnum.
|
||||||
|
|
||||||
noload Don't load the journal on mounting.
|
noload Don't load the journal on mounting. Note that
|
||||||
|
if the filesystem was not unmounted cleanly,
|
||||||
|
skipping the journal replay will lead to the
|
||||||
|
filesystem containing inconsistencies that can
|
||||||
|
lead to any number of problems.
|
||||||
|
|
||||||
data=journal All data are committed into the journal prior to being
|
data=journal All data are committed into the journal prior to being
|
||||||
written into the main file system.
|
written into the main file system.
|
||||||
|
@ -219,9 +229,12 @@ minixdf Make 'df' act like Minix.
|
||||||
|
|
||||||
debug Extra debugging information is sent to syslog.
|
debug Extra debugging information is sent to syslog.
|
||||||
|
|
||||||
errors=remount-ro(*) Remount the filesystem read-only on an error.
|
errors=remount-ro Remount the filesystem read-only on an error.
|
||||||
errors=continue Keep going on a filesystem error.
|
errors=continue Keep going on a filesystem error.
|
||||||
errors=panic Panic and halt the machine if an error occurs.
|
errors=panic Panic and halt the machine if an error occurs.
|
||||||
|
(These mount options override the errors behavior
|
||||||
|
specified in the superblock, which can be configured
|
||||||
|
using tune2fs)
|
||||||
|
|
||||||
data_err=ignore(*) Just print an error message if an error occurs
|
data_err=ignore(*) Just print an error message if an error occurs
|
||||||
in a file data buffer in ordered mode.
|
in a file data buffer in ordered mode.
|
||||||
|
@ -261,6 +274,42 @@ delalloc (*) Deferring block allocation until write-out time.
|
||||||
nodelalloc Disable delayed allocation. Blocks are allocation
|
nodelalloc Disable delayed allocation. Blocks are allocation
|
||||||
when data is copied from user to page cache.
|
when data is copied from user to page cache.
|
||||||
|
|
||||||
|
max_batch_time=usec Maximum amount of time ext4 should wait for
|
||||||
|
additional filesystem operations to be batch
|
||||||
|
together with a synchronous write operation.
|
||||||
|
Since a synchronous write operation is going to
|
||||||
|
force a commit and then a wait for the I/O
|
||||||
|
complete, it doesn't cost much, and can be a
|
||||||
|
huge throughput win, we wait for a small amount
|
||||||
|
of time to see if any other transactions can
|
||||||
|
piggyback on the synchronous write. The
|
||||||
|
algorithm used is designed to automatically tune
|
||||||
|
for the speed of the disk, by measuring the
|
||||||
|
amount of time (on average) that it takes to
|
||||||
|
finish committing a transaction. Call this time
|
||||||
|
the "commit time". If the time that the
|
||||||
|
transactoin has been running is less than the
|
||||||
|
commit time, ext4 will try sleeping for the
|
||||||
|
commit time to see if other operations will join
|
||||||
|
the transaction. The commit time is capped by
|
||||||
|
the max_batch_time, which defaults to 15000us
|
||||||
|
(15ms). This optimization can be turned off
|
||||||
|
entirely by setting max_batch_time to 0.
|
||||||
|
|
||||||
|
min_batch_time=usec This parameter sets the commit time (as
|
||||||
|
described above) to be at least min_batch_time.
|
||||||
|
It defaults to zero microseconds. Increasing
|
||||||
|
this parameter may improve the throughput of
|
||||||
|
multi-threaded, synchronous workloads on very
|
||||||
|
fast disks, at the cost of increasing latency.
|
||||||
|
|
||||||
|
journal_ioprio=prio The I/O priority (from 0 to 7, where 0 is the
|
||||||
|
highest priorty) which should be used for I/O
|
||||||
|
operations submitted by kjournald2 during a
|
||||||
|
commit operation. This defaults to 3, which is
|
||||||
|
a slightly higher priority than the default I/O
|
||||||
|
priority.
|
||||||
|
|
||||||
Data Mode
|
Data Mode
|
||||||
=========
|
=========
|
||||||
There are 3 different data modes:
|
There are 3 different data modes:
|
||||||
|
|
|
@ -76,13 +76,13 @@ the fdtable structure -
|
||||||
5. Handling of the file structures is special. Since the look-up
|
5. Handling of the file structures is special. Since the look-up
|
||||||
of the fd (fget()/fget_light()) are lock-free, it is possible
|
of the fd (fget()/fget_light()) are lock-free, it is possible
|
||||||
that look-up may race with the last put() operation on the
|
that look-up may race with the last put() operation on the
|
||||||
file structure. This is avoided using atomic_inc_not_zero()
|
file structure. This is avoided using atomic_long_inc_not_zero()
|
||||||
on ->f_count :
|
on ->f_count :
|
||||||
|
|
||||||
rcu_read_lock();
|
rcu_read_lock();
|
||||||
file = fcheck_files(files, fd);
|
file = fcheck_files(files, fd);
|
||||||
if (file) {
|
if (file) {
|
||||||
if (atomic_inc_not_zero(&file->f_count))
|
if (atomic_long_inc_not_zero(&file->f_count))
|
||||||
*fput_needed = 1;
|
*fput_needed = 1;
|
||||||
else
|
else
|
||||||
/* Didn't get the reference, someone's freed */
|
/* Didn't get the reference, someone's freed */
|
||||||
|
@ -92,7 +92,7 @@ the fdtable structure -
|
||||||
....
|
....
|
||||||
return file;
|
return file;
|
||||||
|
|
||||||
atomic_inc_not_zero() detects if refcounts is already zero or
|
atomic_long_inc_not_zero() detects if refcounts is already zero or
|
||||||
goes to zero during increment. If it does, we fail
|
goes to zero during increment. If it does, we fail
|
||||||
fget()/fget_light().
|
fget()/fget_light().
|
||||||
|
|
||||||
|
|
|
@ -31,7 +31,6 @@ Features which OCFS2 does not support yet:
|
||||||
- quotas
|
- quotas
|
||||||
- Directory change notification (F_NOTIFY)
|
- Directory change notification (F_NOTIFY)
|
||||||
- Distributed Caching (F_SETLEASE/F_GETLEASE/break_lease)
|
- Distributed Caching (F_SETLEASE/F_GETLEASE/break_lease)
|
||||||
- POSIX ACLs
|
|
||||||
|
|
||||||
Mount options
|
Mount options
|
||||||
=============
|
=============
|
||||||
|
@ -79,3 +78,5 @@ inode64 Indicates that Ocfs2 is allowed to create inodes at
|
||||||
bits of significance.
|
bits of significance.
|
||||||
user_xattr (*) Enables Extended User Attributes.
|
user_xattr (*) Enables Extended User Attributes.
|
||||||
nouser_xattr Disables Extended User Attributes.
|
nouser_xattr Disables Extended User Attributes.
|
||||||
|
acl Enables POSIX Access Control Lists support.
|
||||||
|
noacl (*) Disables POSIX Access Control Lists support.
|
||||||
|
|
|
@ -140,6 +140,7 @@ Table 1-1: Process specific entries in /proc
|
||||||
statm Process memory status information
|
statm Process memory status information
|
||||||
status Process status in human readable form
|
status Process status in human readable form
|
||||||
wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
|
wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
|
||||||
|
stack Report full stack trace, enable via CONFIG_STACKTRACE
|
||||||
smaps Extension based on maps, the rss size for each mapped file
|
smaps Extension based on maps, the rss size for each mapped file
|
||||||
..............................................................................
|
..............................................................................
|
||||||
|
|
||||||
|
@ -1339,10 +1340,13 @@ nmi_watchdog
|
||||||
|
|
||||||
Enables/Disables the NMI watchdog on x86 systems. When the value is non-zero
|
Enables/Disables the NMI watchdog on x86 systems. When the value is non-zero
|
||||||
the NMI watchdog is enabled and will continuously test all online cpus to
|
the NMI watchdog is enabled and will continuously test all online cpus to
|
||||||
determine whether or not they are still functioning properly.
|
determine whether or not they are still functioning properly. Currently,
|
||||||
|
passing "nmi_watchdog=" parameter at boot time is required for this function
|
||||||
|
to work.
|
||||||
|
|
||||||
Because the NMI watchdog shares registers with oprofile, by disabling the NMI
|
If LAPIC NMI watchdog method is in use (nmi_watchdog=2 kernel parameter), the
|
||||||
watchdog, oprofile may have more registers to utilize.
|
NMI watchdog shares registers with oprofile. By disabling the NMI watchdog,
|
||||||
|
oprofile may have more registers to utilize.
|
||||||
|
|
||||||
msgmni
|
msgmni
|
||||||
------
|
------
|
||||||
|
@ -1367,268 +1371,8 @@ auto_msgmni default value is 1.
|
||||||
2.4 /proc/sys/vm - The virtual memory subsystem
|
2.4 /proc/sys/vm - The virtual memory subsystem
|
||||||
-----------------------------------------------
|
-----------------------------------------------
|
||||||
|
|
||||||
The files in this directory can be used to tune the operation of the virtual
|
Please see: Documentation/sysctls/vm.txt for a description of these
|
||||||
memory (VM) subsystem of the Linux kernel.
|
entries.
|
||||||
|
|
||||||
vfs_cache_pressure
|
|
||||||
------------------
|
|
||||||
|
|
||||||
Controls the tendency of the kernel to reclaim the memory which is used for
|
|
||||||
caching of directory and inode objects.
|
|
||||||
|
|
||||||
At the default value of vfs_cache_pressure=100 the kernel will attempt to
|
|
||||||
reclaim dentries and inodes at a "fair" rate with respect to pagecache and
|
|
||||||
swapcache reclaim. Decreasing vfs_cache_pressure causes the kernel to prefer
|
|
||||||
to retain dentry and inode caches. Increasing vfs_cache_pressure beyond 100
|
|
||||||
causes the kernel to prefer to reclaim dentries and inodes.
|
|
||||||
|
|
||||||
dirty_background_ratio
|
|
||||||
----------------------
|
|
||||||
|
|
||||||
Contains, as a percentage of the dirtyable system memory (free pages + mapped
|
|
||||||
pages + file cache, not including locked pages and HugePages), the number of
|
|
||||||
pages at which the pdflush background writeback daemon will start writing out
|
|
||||||
dirty data.
|
|
||||||
|
|
||||||
dirty_ratio
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
Contains, as a percentage of the dirtyable system memory (free pages + mapped
|
|
||||||
pages + file cache, not including locked pages and HugePages), the number of
|
|
||||||
pages at which a process which is generating disk writes will itself start
|
|
||||||
writing out dirty data.
|
|
||||||
|
|
||||||
dirty_writeback_centisecs
|
|
||||||
-------------------------
|
|
||||||
|
|
||||||
The pdflush writeback daemons will periodically wake up and write `old' data
|
|
||||||
out to disk. This tunable expresses the interval between those wakeups, in
|
|
||||||
100'ths of a second.
|
|
||||||
|
|
||||||
Setting this to zero disables periodic writeback altogether.
|
|
||||||
|
|
||||||
dirty_expire_centisecs
|
|
||||||
----------------------
|
|
||||||
|
|
||||||
This tunable is used to define when dirty data is old enough to be eligible
|
|
||||||
for writeout by the pdflush daemons. It is expressed in 100'ths of a second.
|
|
||||||
Data which has been dirty in-memory for longer than this interval will be
|
|
||||||
written out next time a pdflush daemon wakes up.
|
|
||||||
|
|
||||||
highmem_is_dirtyable
|
|
||||||
--------------------
|
|
||||||
|
|
||||||
Only present if CONFIG_HIGHMEM is set.
|
|
||||||
|
|
||||||
This defaults to 0 (false), meaning that the ratios set above are calculated
|
|
||||||
as a percentage of lowmem only. This protects against excessive scanning
|
|
||||||
in page reclaim, swapping and general VM distress.
|
|
||||||
|
|
||||||
Setting this to 1 can be useful on 32 bit machines where you want to make
|
|
||||||
random changes within an MMAPed file that is larger than your available
|
|
||||||
lowmem without causing large quantities of random IO. Is is safe if the
|
|
||||||
behavior of all programs running on the machine is known and memory will
|
|
||||||
not be otherwise stressed.
|
|
||||||
|
|
||||||
legacy_va_layout
|
|
||||||
----------------
|
|
||||||
|
|
||||||
If non-zero, this sysctl disables the new 32-bit mmap mmap layout - the kernel
|
|
||||||
will use the legacy (2.4) layout for all processes.
|
|
||||||
|
|
||||||
lowmem_reserve_ratio
|
|
||||||
---------------------
|
|
||||||
|
|
||||||
For some specialised workloads on highmem machines it is dangerous for
|
|
||||||
the kernel to allow process memory to be allocated from the "lowmem"
|
|
||||||
zone. This is because that memory could then be pinned via the mlock()
|
|
||||||
system call, or by unavailability of swapspace.
|
|
||||||
|
|
||||||
And on large highmem machines this lack of reclaimable lowmem memory
|
|
||||||
can be fatal.
|
|
||||||
|
|
||||||
So the Linux page allocator has a mechanism which prevents allocations
|
|
||||||
which _could_ use highmem from using too much lowmem. This means that
|
|
||||||
a certain amount of lowmem is defended from the possibility of being
|
|
||||||
captured into pinned user memory.
|
|
||||||
|
|
||||||
(The same argument applies to the old 16 megabyte ISA DMA region. This
|
|
||||||
mechanism will also defend that region from allocations which could use
|
|
||||||
highmem or lowmem).
|
|
||||||
|
|
||||||
The `lowmem_reserve_ratio' tunable determines how aggressive the kernel is
|
|
||||||
in defending these lower zones.
|
|
||||||
|
|
||||||
If you have a machine which uses highmem or ISA DMA and your
|
|
||||||
applications are using mlock(), or if you are running with no swap then
|
|
||||||
you probably should change the lowmem_reserve_ratio setting.
|
|
||||||
|
|
||||||
The lowmem_reserve_ratio is an array. You can see them by reading this file.
|
|
||||||
-
|
|
||||||
% cat /proc/sys/vm/lowmem_reserve_ratio
|
|
||||||
256 256 32
|
|
||||||
-
|
|
||||||
Note: # of this elements is one fewer than number of zones. Because the highest
|
|
||||||
zone's value is not necessary for following calculation.
|
|
||||||
|
|
||||||
But, these values are not used directly. The kernel calculates # of protection
|
|
||||||
pages for each zones from them. These are shown as array of protection pages
|
|
||||||
in /proc/zoneinfo like followings. (This is an example of x86-64 box).
|
|
||||||
Each zone has an array of protection pages like this.
|
|
||||||
|
|
||||||
-
|
|
||||||
Node 0, zone DMA
|
|
||||||
pages free 1355
|
|
||||||
min 3
|
|
||||||
low 3
|
|
||||||
high 4
|
|
||||||
:
|
|
||||||
:
|
|
||||||
numa_other 0
|
|
||||||
protection: (0, 2004, 2004, 2004)
|
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
||||||
pagesets
|
|
||||||
cpu: 0 pcp: 0
|
|
||||||
:
|
|
||||||
-
|
|
||||||
These protections are added to score to judge whether this zone should be used
|
|
||||||
for page allocation or should be reclaimed.
|
|
||||||
|
|
||||||
In this example, if normal pages (index=2) are required to this DMA zone and
|
|
||||||
pages_high is used for watermark, the kernel judges this zone should not be
|
|
||||||
used because pages_free(1355) is smaller than watermark + protection[2]
|
|
||||||
(4 + 2004 = 2008). If this protection value is 0, this zone would be used for
|
|
||||||
normal page requirement. If requirement is DMA zone(index=0), protection[0]
|
|
||||||
(=0) is used.
|
|
||||||
|
|
||||||
zone[i]'s protection[j] is calculated by following expression.
|
|
||||||
|
|
||||||
(i < j):
|
|
||||||
zone[i]->protection[j]
|
|
||||||
= (total sums of present_pages from zone[i+1] to zone[j] on the node)
|
|
||||||
/ lowmem_reserve_ratio[i];
|
|
||||||
(i = j):
|
|
||||||
(should not be protected. = 0;
|
|
||||||
(i > j):
|
|
||||||
(not necessary, but looks 0)
|
|
||||||
|
|
||||||
The default values of lowmem_reserve_ratio[i] are
|
|
||||||
256 (if zone[i] means DMA or DMA32 zone)
|
|
||||||
32 (others).
|
|
||||||
As above expression, they are reciprocal number of ratio.
|
|
||||||
256 means 1/256. # of protection pages becomes about "0.39%" of total present
|
|
||||||
pages of higher zones on the node.
|
|
||||||
|
|
||||||
If you would like to protect more pages, smaller values are effective.
|
|
||||||
The minimum value is 1 (1/1 -> 100%).
|
|
||||||
|
|
||||||
page-cluster
|
|
||||||
------------
|
|
||||||
|
|
||||||
page-cluster controls the number of pages which are written to swap in
|
|
||||||
a single attempt. The swap I/O size.
|
|
||||||
|
|
||||||
It is a logarithmic value - setting it to zero means "1 page", setting
|
|
||||||
it to 1 means "2 pages", setting it to 2 means "4 pages", etc.
|
|
||||||
|
|
||||||
The default value is three (eight pages at a time). There may be some
|
|
||||||
small benefits in tuning this to a different value if your workload is
|
|
||||||
swap-intensive.
|
|
||||||
|
|
||||||
overcommit_memory
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
Controls overcommit of system memory, possibly allowing processes
|
|
||||||
to allocate (but not use) more memory than is actually available.
|
|
||||||
|
|
||||||
|
|
||||||
0 - Heuristic overcommit handling. Obvious overcommits of
|
|
||||||
address space are refused. Used for a typical system. It
|
|
||||||
ensures a seriously wild allocation fails while allowing
|
|
||||||
overcommit to reduce swap usage. root is allowed to
|
|
||||||
allocate slightly more memory in this mode. This is the
|
|
||||||
default.
|
|
||||||
|
|
||||||
1 - Always overcommit. Appropriate for some scientific
|
|
||||||
applications.
|
|
||||||
|
|
||||||
2 - Don't overcommit. The total address space commit
|
|
||||||
for the system is not permitted to exceed swap plus a
|
|
||||||
configurable percentage (default is 50) of physical RAM.
|
|
||||||
Depending on the percentage you use, in most situations
|
|
||||||
this means a process will not be killed while attempting
|
|
||||||
to use already-allocated memory but will receive errors
|
|
||||||
on memory allocation as appropriate.
|
|
||||||
|
|
||||||
overcommit_ratio
|
|
||||||
----------------
|
|
||||||
|
|
||||||
Percentage of physical memory size to include in overcommit calculations
|
|
||||||
(see above.)
|
|
||||||
|
|
||||||
Memory allocation limit = swapspace + physmem * (overcommit_ratio / 100)
|
|
||||||
|
|
||||||
swapspace = total size of all swap areas
|
|
||||||
physmem = size of physical memory in system
|
|
||||||
|
|
||||||
nr_hugepages and hugetlb_shm_group
|
|
||||||
----------------------------------
|
|
||||||
|
|
||||||
nr_hugepages configures number of hugetlb page reserved for the system.
|
|
||||||
|
|
||||||
hugetlb_shm_group contains group id that is allowed to create SysV shared
|
|
||||||
memory segment using hugetlb page.
|
|
||||||
|
|
||||||
hugepages_treat_as_movable
|
|
||||||
--------------------------
|
|
||||||
|
|
||||||
This parameter is only useful when kernelcore= is specified at boot time to
|
|
||||||
create ZONE_MOVABLE for pages that may be reclaimed or migrated. Huge pages
|
|
||||||
are not movable so are not normally allocated from ZONE_MOVABLE. A non-zero
|
|
||||||
value written to hugepages_treat_as_movable allows huge pages to be allocated
|
|
||||||
from ZONE_MOVABLE.
|
|
||||||
|
|
||||||
Once enabled, the ZONE_MOVABLE is treated as an area of memory the huge
|
|
||||||
pages pool can easily grow or shrink within. Assuming that applications are
|
|
||||||
not running that mlock() a lot of memory, it is likely the huge pages pool
|
|
||||||
can grow to the size of ZONE_MOVABLE by repeatedly entering the desired value
|
|
||||||
into nr_hugepages and triggering page reclaim.
|
|
||||||
|
|
||||||
laptop_mode
|
|
||||||
-----------
|
|
||||||
|
|
||||||
laptop_mode is a knob that controls "laptop mode". All the things that are
|
|
||||||
controlled by this knob are discussed in Documentation/laptops/laptop-mode.txt.
|
|
||||||
|
|
||||||
block_dump
|
|
||||||
----------
|
|
||||||
|
|
||||||
block_dump enables block I/O debugging when set to a nonzero value. More
|
|
||||||
information on block I/O debugging is in Documentation/laptops/laptop-mode.txt.
|
|
||||||
|
|
||||||
swap_token_timeout
|
|
||||||
------------------
|
|
||||||
|
|
||||||
This file contains valid hold time of swap out protection token. The Linux
|
|
||||||
VM has token based thrashing control mechanism and uses the token to prevent
|
|
||||||
unnecessary page faults in thrashing situation. The unit of the value is
|
|
||||||
second. The value would be useful to tune thrashing behavior.
|
|
||||||
|
|
||||||
drop_caches
|
|
||||||
-----------
|
|
||||||
|
|
||||||
Writing to this will cause the kernel to drop clean caches, dentries and
|
|
||||||
inodes from memory, causing that memory to become free.
|
|
||||||
|
|
||||||
To free pagecache:
|
|
||||||
echo 1 > /proc/sys/vm/drop_caches
|
|
||||||
To free dentries and inodes:
|
|
||||||
echo 2 > /proc/sys/vm/drop_caches
|
|
||||||
To free pagecache, dentries and inodes:
|
|
||||||
echo 3 > /proc/sys/vm/drop_caches
|
|
||||||
|
|
||||||
As this is a non-destructive operation and dirty objects are not freeable, the
|
|
||||||
user should run `sync' first.
|
|
||||||
|
|
||||||
|
|
||||||
2.5 /proc/sys/dev - Device specific parameters
|
2.5 /proc/sys/dev - Device specific parameters
|
||||||
|
|
|
@ -0,0 +1,225 @@
|
||||||
|
SQUASHFS 4.0 FILESYSTEM
|
||||||
|
=======================
|
||||||
|
|
||||||
|
Squashfs is a compressed read-only filesystem for Linux.
|
||||||
|
It uses zlib compression to compress files, inodes and directories.
|
||||||
|
Inodes in the system are very small and all blocks are packed to minimise
|
||||||
|
data overhead. Block sizes greater than 4K are supported up to a maximum
|
||||||
|
of 1Mbytes (default block size 128K).
|
||||||
|
|
||||||
|
Squashfs is intended for general read-only filesystem use, for archival
|
||||||
|
use (i.e. in cases where a .tar.gz file may be used), and in constrained
|
||||||
|
block device/memory systems (e.g. embedded systems) where low overhead is
|
||||||
|
needed.
|
||||||
|
|
||||||
|
Mailing list: squashfs-devel@lists.sourceforge.net
|
||||||
|
Web site: www.squashfs.org
|
||||||
|
|
||||||
|
1. FILESYSTEM FEATURES
|
||||||
|
----------------------
|
||||||
|
|
||||||
|
Squashfs filesystem features versus Cramfs:
|
||||||
|
|
||||||
|
Squashfs Cramfs
|
||||||
|
|
||||||
|
Max filesystem size: 2^64 16 MiB
|
||||||
|
Max file size: ~ 2 TiB 16 MiB
|
||||||
|
Max files: unlimited unlimited
|
||||||
|
Max directories: unlimited unlimited
|
||||||
|
Max entries per directory: unlimited unlimited
|
||||||
|
Max block size: 1 MiB 4 KiB
|
||||||
|
Metadata compression: yes no
|
||||||
|
Directory indexes: yes no
|
||||||
|
Sparse file support: yes no
|
||||||
|
Tail-end packing (fragments): yes no
|
||||||
|
Exportable (NFS etc.): yes no
|
||||||
|
Hard link support: yes no
|
||||||
|
"." and ".." in readdir: yes no
|
||||||
|
Real inode numbers: yes no
|
||||||
|
32-bit uids/gids: yes no
|
||||||
|
File creation time: yes no
|
||||||
|
Xattr and ACL support: no no
|
||||||
|
|
||||||
|
Squashfs compresses data, inodes and directories. In addition, inode and
|
||||||
|
directory data are highly compacted, and packed on byte boundaries. Each
|
||||||
|
compressed inode is on average 8 bytes in length (the exact length varies on
|
||||||
|
file type, i.e. regular file, directory, symbolic link, and block/char device
|
||||||
|
inodes have different sizes).
|
||||||
|
|
||||||
|
2. USING SQUASHFS
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
As squashfs is a read-only filesystem, the mksquashfs program must be used to
|
||||||
|
create populated squashfs filesystems. This and other squashfs utilities
|
||||||
|
can be obtained from http://www.squashfs.org. Usage instructions can be
|
||||||
|
obtained from this site also.
|
||||||
|
|
||||||
|
|
||||||
|
3. SQUASHFS FILESYSTEM DESIGN
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
A squashfs filesystem consists of seven parts, packed together on a byte
|
||||||
|
alignment:
|
||||||
|
|
||||||
|
---------------
|
||||||
|
| superblock |
|
||||||
|
|---------------|
|
||||||
|
| datablocks |
|
||||||
|
| & fragments |
|
||||||
|
|---------------|
|
||||||
|
| inode table |
|
||||||
|
|---------------|
|
||||||
|
| directory |
|
||||||
|
| table |
|
||||||
|
|---------------|
|
||||||
|
| fragment |
|
||||||
|
| table |
|
||||||
|
|---------------|
|
||||||
|
| export |
|
||||||
|
| table |
|
||||||
|
|---------------|
|
||||||
|
| uid/gid |
|
||||||
|
| lookup table |
|
||||||
|
---------------
|
||||||
|
|
||||||
|
Compressed data blocks are written to the filesystem as files are read from
|
||||||
|
the source directory, and checked for duplicates. Once all file data has been
|
||||||
|
written the completed inode, directory, fragment, export and uid/gid lookup
|
||||||
|
tables are written.
|
||||||
|
|
||||||
|
3.1 Inodes
|
||||||
|
----------
|
||||||
|
|
||||||
|
Metadata (inodes and directories) are compressed in 8Kbyte blocks. Each
|
||||||
|
compressed block is prefixed by a two byte length, the top bit is set if the
|
||||||
|
block is uncompressed. A block will be uncompressed if the -noI option is set,
|
||||||
|
or if the compressed block was larger than the uncompressed block.
|
||||||
|
|
||||||
|
Inodes are packed into the metadata blocks, and are not aligned to block
|
||||||
|
boundaries, therefore inodes overlap compressed blocks. Inodes are identified
|
||||||
|
by a 48-bit number which encodes the location of the compressed metadata block
|
||||||
|
containing the inode, and the byte offset into that block where the inode is
|
||||||
|
placed (<block, offset>).
|
||||||
|
|
||||||
|
To maximise compression there are different inodes for each file type
|
||||||
|
(regular file, directory, device, etc.), the inode contents and length
|
||||||
|
varying with the type.
|
||||||
|
|
||||||
|
To further maximise compression, two types of regular file inode and
|
||||||
|
directory inode are defined: inodes optimised for frequently occurring
|
||||||
|
regular files and directories, and extended types where extra
|
||||||
|
information has to be stored.
|
||||||
|
|
||||||
|
3.2 Directories
|
||||||
|
---------------
|
||||||
|
|
||||||
|
Like inodes, directories are packed into compressed metadata blocks, stored
|
||||||
|
in a directory table. Directories are accessed using the start address of
|
||||||
|
the metablock containing the directory and the offset into the
|
||||||
|
decompressed block (<block, offset>).
|
||||||
|
|
||||||
|
Directories are organised in a slightly complex way, and are not simply
|
||||||
|
a list of file names. The organisation takes advantage of the
|
||||||
|
fact that (in most cases) the inodes of the files will be in the same
|
||||||
|
compressed metadata block, and therefore, can share the start block.
|
||||||
|
Directories are therefore organised in a two level list, a directory
|
||||||
|
header containing the shared start block value, and a sequence of directory
|
||||||
|
entries, each of which share the shared start block. A new directory header
|
||||||
|
is written once/if the inode start block changes. The directory
|
||||||
|
header/directory entry list is repeated as many times as necessary.
|
||||||
|
|
||||||
|
Directories are sorted, and can contain a directory index to speed up
|
||||||
|
file lookup. Directory indexes store one entry per metablock, each entry
|
||||||
|
storing the index/filename mapping to the first directory header
|
||||||
|
in each metadata block. Directories are sorted in alphabetical order,
|
||||||
|
and at lookup the index is scanned linearly looking for the first filename
|
||||||
|
alphabetically larger than the filename being looked up. At this point the
|
||||||
|
location of the metadata block the filename is in has been found.
|
||||||
|
The general idea of the index is ensure only one metadata block needs to be
|
||||||
|
decompressed to do a lookup irrespective of the length of the directory.
|
||||||
|
This scheme has the advantage that it doesn't require extra memory overhead
|
||||||
|
and doesn't require much extra storage on disk.
|
||||||
|
|
||||||
|
3.3 File data
|
||||||
|
-------------
|
||||||
|
|
||||||
|
Regular files consist of a sequence of contiguous compressed blocks, and/or a
|
||||||
|
compressed fragment block (tail-end packed block). The compressed size
|
||||||
|
of each datablock is stored in a block list contained within the
|
||||||
|
file inode.
|
||||||
|
|
||||||
|
To speed up access to datablocks when reading 'large' files (256 Mbytes or
|
||||||
|
larger), the code implements an index cache that caches the mapping from
|
||||||
|
block index to datablock location on disk.
|
||||||
|
|
||||||
|
The index cache allows Squashfs to handle large files (up to 1.75 TiB) while
|
||||||
|
retaining a simple and space-efficient block list on disk. The cache
|
||||||
|
is split into slots, caching up to eight 224 GiB files (128 KiB blocks).
|
||||||
|
Larger files use multiple slots, with 1.75 TiB files using all 8 slots.
|
||||||
|
The index cache is designed to be memory efficient, and by default uses
|
||||||
|
16 KiB.
|
||||||
|
|
||||||
|
3.4 Fragment lookup table
|
||||||
|
-------------------------
|
||||||
|
|
||||||
|
Regular files can contain a fragment index which is mapped to a fragment
|
||||||
|
location on disk and compressed size using a fragment lookup table. This
|
||||||
|
fragment lookup table is itself stored compressed into metadata blocks.
|
||||||
|
A second index table is used to locate these. This second index table for
|
||||||
|
speed of access (and because it is small) is read at mount time and cached
|
||||||
|
in memory.
|
||||||
|
|
||||||
|
3.5 Uid/gid lookup table
|
||||||
|
------------------------
|
||||||
|
|
||||||
|
For space efficiency regular files store uid and gid indexes, which are
|
||||||
|
converted to 32-bit uids/gids using an id look up table. This table is
|
||||||
|
stored compressed into metadata blocks. A second index table is used to
|
||||||
|
locate these. This second index table for speed of access (and because it
|
||||||
|
is small) is read at mount time and cached in memory.
|
||||||
|
|
||||||
|
3.6 Export table
|
||||||
|
----------------
|
||||||
|
|
||||||
|
To enable Squashfs filesystems to be exportable (via NFS etc.) filesystems
|
||||||
|
can optionally (disabled with the -no-exports Mksquashfs option) contain
|
||||||
|
an inode number to inode disk location lookup table. This is required to
|
||||||
|
enable Squashfs to map inode numbers passed in filehandles to the inode
|
||||||
|
location on disk, which is necessary when the export code reinstantiates
|
||||||
|
expired/flushed inodes.
|
||||||
|
|
||||||
|
This table is stored compressed into metadata blocks. A second index table is
|
||||||
|
used to locate these. This second index table for speed of access (and because
|
||||||
|
it is small) is read at mount time and cached in memory.
|
||||||
|
|
||||||
|
|
||||||
|
4. TODOS AND OUTSTANDING ISSUES
|
||||||
|
-------------------------------
|
||||||
|
|
||||||
|
4.1 Todo list
|
||||||
|
-------------
|
||||||
|
|
||||||
|
Implement Xattr and ACL support. The Squashfs 4.0 filesystem layout has hooks
|
||||||
|
for these but the code has not been written. Once the code has been written
|
||||||
|
the existing layout should not require modification.
|
||||||
|
|
||||||
|
4.2 Squashfs internal cache
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
Blocks in Squashfs are compressed. To avoid repeatedly decompressing
|
||||||
|
recently accessed data Squashfs uses two small metadata and fragment caches.
|
||||||
|
|
||||||
|
The cache is not used for file datablocks, these are decompressed and cached in
|
||||||
|
the page-cache in the normal way. The cache is used to temporarily cache
|
||||||
|
fragment and metadata blocks which have been read as a result of a metadata
|
||||||
|
(i.e. inode or directory) or fragment access. Because metadata and fragments
|
||||||
|
are packed together into blocks (to gain greater compression) the read of a
|
||||||
|
particular piece of metadata or fragment will retrieve other metadata/fragments
|
||||||
|
which have been packed with it, these because of locality-of-reference may be
|
||||||
|
read in the near future. Temporarily caching them ensures they are available
|
||||||
|
for near future access without requiring an additional read and decompress.
|
||||||
|
|
||||||
|
In the future this internal cache may be replaced with an implementation which
|
||||||
|
uses the kernel page cache. Because the page cache operates on page sized
|
||||||
|
units this may introduce additional complexity in terms of locking and
|
||||||
|
associated race conditions.
|
|
@ -95,6 +95,9 @@ no_chk_data_crc skip checking of CRCs on data nodes in order to
|
||||||
of this option is that corruption of the contents
|
of this option is that corruption of the contents
|
||||||
of a file can go unnoticed.
|
of a file can go unnoticed.
|
||||||
chk_data_crc (*) do not skip checking CRCs on data nodes
|
chk_data_crc (*) do not skip checking CRCs on data nodes
|
||||||
|
compr=none override default compressor and set it to "none"
|
||||||
|
compr=lzo override default compressor and set it to "lzo"
|
||||||
|
compr=zlib override default compressor and set it to "zlib"
|
||||||
|
|
||||||
|
|
||||||
Quick usage instructions
|
Quick usage instructions
|
||||||
|
|
|
@ -210,8 +210,8 @@ struct super_operations {
|
||||||
void (*put_super) (struct super_block *);
|
void (*put_super) (struct super_block *);
|
||||||
void (*write_super) (struct super_block *);
|
void (*write_super) (struct super_block *);
|
||||||
int (*sync_fs)(struct super_block *sb, int wait);
|
int (*sync_fs)(struct super_block *sb, int wait);
|
||||||
void (*write_super_lockfs) (struct super_block *);
|
int (*freeze_fs) (struct super_block *);
|
||||||
void (*unlockfs) (struct super_block *);
|
int (*unfreeze_fs) (struct super_block *);
|
||||||
int (*statfs) (struct dentry *, struct kstatfs *);
|
int (*statfs) (struct dentry *, struct kstatfs *);
|
||||||
int (*remount_fs) (struct super_block *, int *, char *);
|
int (*remount_fs) (struct super_block *, int *, char *);
|
||||||
void (*clear_inode) (struct inode *);
|
void (*clear_inode) (struct inode *);
|
||||||
|
@ -270,11 +270,11 @@ or bottom half).
|
||||||
a superblock. The second parameter indicates whether the method
|
a superblock. The second parameter indicates whether the method
|
||||||
should wait until the write out has been completed. Optional.
|
should wait until the write out has been completed. Optional.
|
||||||
|
|
||||||
write_super_lockfs: called when VFS is locking a filesystem and
|
freeze_fs: called when VFS is locking a filesystem and
|
||||||
forcing it into a consistent state. This method is currently
|
forcing it into a consistent state. This method is currently
|
||||||
used by the Logical Volume Manager (LVM).
|
used by the Logical Volume Manager (LVM).
|
||||||
|
|
||||||
unlockfs: called when VFS is unlocking a filesystem and making it writable
|
unfreeze_fs: called when VFS is unlocking a filesystem and making it writable
|
||||||
again.
|
again.
|
||||||
|
|
||||||
statfs: called when the VFS needs to get filesystem statistics. This
|
statfs: called when the VFS needs to get filesystem statistics. This
|
||||||
|
@ -733,7 +733,6 @@ struct file_operations {
|
||||||
ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
|
ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
|
||||||
unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
|
unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
|
||||||
int (*check_flags)(int);
|
int (*check_flags)(int);
|
||||||
int (*dir_notify)(struct file *filp, unsigned long arg);
|
|
||||||
int (*flock) (struct file *, int, struct file_lock *);
|
int (*flock) (struct file *, int, struct file_lock *);
|
||||||
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, size_t, unsigned int);
|
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, size_t, unsigned int);
|
||||||
ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned int);
|
ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned int);
|
||||||
|
@ -800,8 +799,6 @@ otherwise noted.
|
||||||
|
|
||||||
check_flags: called by the fcntl(2) system call for F_SETFL command
|
check_flags: called by the fcntl(2) system call for F_SETFL command
|
||||||
|
|
||||||
dir_notify: called by the fcntl(2) system call for F_NOTIFY command
|
|
||||||
|
|
||||||
flock: called by the flock(2) system call
|
flock: called by the flock(2) system call
|
||||||
|
|
||||||
splice_write: called by the VFS to splice data from a pipe to a file. This
|
splice_write: called by the VFS to splice data from a pipe to a file. This
|
||||||
|
@ -931,7 +928,7 @@ manipulate dentries:
|
||||||
d_lookup: look up a dentry given its parent and path name component
|
d_lookup: look up a dentry given its parent and path name component
|
||||||
It looks up the child of that given name from the dcache
|
It looks up the child of that given name from the dcache
|
||||||
hash table. If it is found, the reference count is incremented
|
hash table. If it is found, the reference count is incremented
|
||||||
and the dentry is returned. The caller must use d_put()
|
and the dentry is returned. The caller must use dput()
|
||||||
to free the dentry when it finishes using it.
|
to free the dentry when it finishes using it.
|
||||||
|
|
||||||
For further information on dentry locking, please refer to the document
|
For further information on dentry locking, please refer to the document
|
||||||
|
|
|
@ -229,10 +229,6 @@ The following sysctls are available for the XFS filesystem:
|
||||||
ISGID bit is cleared if the irix_sgid_inherit compatibility sysctl
|
ISGID bit is cleared if the irix_sgid_inherit compatibility sysctl
|
||||||
is set.
|
is set.
|
||||||
|
|
||||||
fs.xfs.restrict_chown (Min: 0 Default: 1 Max: 1)
|
|
||||||
Controls whether unprivileged users can use chown to "give away"
|
|
||||||
a file to another user.
|
|
||||||
|
|
||||||
fs.xfs.inherit_sync (Min: 0 Default: 1 Max: 1)
|
fs.xfs.inherit_sync (Min: 0 Default: 1 Max: 1)
|
||||||
Setting this to "1" will cause the "sync" flag set
|
Setting this to "1" will cause the "sync" flag set
|
||||||
by the xfs_io(8) chattr command on a directory to be
|
by the xfs_io(8) chattr command on a directory to be
|
||||||
|
|
|
@ -82,7 +82,7 @@ of ftrace. Here is a list of some of the key files:
|
||||||
tracer is not adding more data, they will display
|
tracer is not adding more data, they will display
|
||||||
the same information every time they are read.
|
the same information every time they are read.
|
||||||
|
|
||||||
iter_ctrl: This file lets the user control the amount of data
|
trace_options: This file lets the user control the amount of data
|
||||||
that is displayed in one of the above output
|
that is displayed in one of the above output
|
||||||
files.
|
files.
|
||||||
|
|
||||||
|
@ -94,7 +94,7 @@ of ftrace. Here is a list of some of the key files:
|
||||||
only be recorded if the latency is greater than
|
only be recorded if the latency is greater than
|
||||||
the value in this file. (in microseconds)
|
the value in this file. (in microseconds)
|
||||||
|
|
||||||
trace_entries: This sets or displays the number of bytes each CPU
|
buffer_size_kb: This sets or displays the number of kilobytes each CPU
|
||||||
buffer can hold. The tracer buffers are the same size
|
buffer can hold. The tracer buffers are the same size
|
||||||
for each CPU. The displayed number is the size of the
|
for each CPU. The displayed number is the size of the
|
||||||
CPU buffer and not total size of all buffers. The
|
CPU buffer and not total size of all buffers. The
|
||||||
|
@ -127,6 +127,8 @@ of ftrace. Here is a list of some of the key files:
|
||||||
be traced. If a function exists in both set_ftrace_filter
|
be traced. If a function exists in both set_ftrace_filter
|
||||||
and set_ftrace_notrace, the function will _not_ be traced.
|
and set_ftrace_notrace, the function will _not_ be traced.
|
||||||
|
|
||||||
|
set_ftrace_pid: Have the function tracer only trace a single thread.
|
||||||
|
|
||||||
available_filter_functions: This lists the functions that ftrace
|
available_filter_functions: This lists the functions that ftrace
|
||||||
has processed and can trace. These are the function
|
has processed and can trace. These are the function
|
||||||
names that you can pass to "set_ftrace_filter" or
|
names that you can pass to "set_ftrace_filter" or
|
||||||
|
@ -316,23 +318,23 @@ The above is mostly meaningful for kernel developers.
|
||||||
The rest is the same as the 'trace' file.
|
The rest is the same as the 'trace' file.
|
||||||
|
|
||||||
|
|
||||||
iter_ctrl
|
trace_options
|
||||||
---------
|
-------------
|
||||||
|
|
||||||
The iter_ctrl file is used to control what gets printed in the trace
|
The trace_options file is used to control what gets printed in the trace
|
||||||
output. To see what is available, simply cat the file:
|
output. To see what is available, simply cat the file:
|
||||||
|
|
||||||
cat /debug/tracing/iter_ctrl
|
cat /debug/tracing/trace_options
|
||||||
print-parent nosym-offset nosym-addr noverbose noraw nohex nobin \
|
print-parent nosym-offset nosym-addr noverbose noraw nohex nobin \
|
||||||
noblock nostacktrace nosched-tree
|
noblock nostacktrace nosched-tree nouserstacktrace nosym-userobj
|
||||||
|
|
||||||
To disable one of the options, echo in the option prepended with "no".
|
To disable one of the options, echo in the option prepended with "no".
|
||||||
|
|
||||||
echo noprint-parent > /debug/tracing/iter_ctrl
|
echo noprint-parent > /debug/tracing/trace_options
|
||||||
|
|
||||||
To enable an option, leave off the "no".
|
To enable an option, leave off the "no".
|
||||||
|
|
||||||
echo sym-offset > /debug/tracing/iter_ctrl
|
echo sym-offset > /debug/tracing/trace_options
|
||||||
|
|
||||||
Here are the available options:
|
Here are the available options:
|
||||||
|
|
||||||
|
@ -378,6 +380,20 @@ Here are the available options:
|
||||||
When a trace is recorded, so is the stack of functions.
|
When a trace is recorded, so is the stack of functions.
|
||||||
This allows for back traces of trace sites.
|
This allows for back traces of trace sites.
|
||||||
|
|
||||||
|
userstacktrace - This option changes the trace.
|
||||||
|
It records a stacktrace of the current userspace thread.
|
||||||
|
|
||||||
|
sym-userobj - when user stacktrace are enabled, look up which object the
|
||||||
|
address belongs to, and print a relative address
|
||||||
|
This is especially useful when ASLR is on, otherwise you don't
|
||||||
|
get a chance to resolve the address to object/file/line after the app is no
|
||||||
|
longer running
|
||||||
|
|
||||||
|
The lookup is performed when you read trace,trace_pipe,latency_trace. Example:
|
||||||
|
|
||||||
|
a.out-1623 [000] 40874.465068: /root/a.out[+0x480] <-/root/a.out[+0
|
||||||
|
x494] <- /root/a.out[+0x4a8] <- /lib/libc-2.7.so[+0x1e1a6]
|
||||||
|
|
||||||
sched-tree - TBD (any users??)
|
sched-tree - TBD (any users??)
|
||||||
|
|
||||||
|
|
||||||
|
@ -1059,6 +1075,83 @@ For simple one time traces, the above is sufficent. For anything else,
|
||||||
a search through /proc/mounts may be needed to find where the debugfs
|
a search through /proc/mounts may be needed to find where the debugfs
|
||||||
file-system is mounted.
|
file-system is mounted.
|
||||||
|
|
||||||
|
|
||||||
|
Single thread tracing
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
By writing into /debug/tracing/set_ftrace_pid you can trace a
|
||||||
|
single thread. For example:
|
||||||
|
|
||||||
|
# cat /debug/tracing/set_ftrace_pid
|
||||||
|
no pid
|
||||||
|
# echo 3111 > /debug/tracing/set_ftrace_pid
|
||||||
|
# cat /debug/tracing/set_ftrace_pid
|
||||||
|
3111
|
||||||
|
# echo function > /debug/tracing/current_tracer
|
||||||
|
# cat /debug/tracing/trace | head
|
||||||
|
# tracer: function
|
||||||
|
#
|
||||||
|
# TASK-PID CPU# TIMESTAMP FUNCTION
|
||||||
|
# | | | | |
|
||||||
|
yum-updatesd-3111 [003] 1637.254676: finish_task_switch <-thread_return
|
||||||
|
yum-updatesd-3111 [003] 1637.254681: hrtimer_cancel <-schedule_hrtimeout_range
|
||||||
|
yum-updatesd-3111 [003] 1637.254682: hrtimer_try_to_cancel <-hrtimer_cancel
|
||||||
|
yum-updatesd-3111 [003] 1637.254683: lock_hrtimer_base <-hrtimer_try_to_cancel
|
||||||
|
yum-updatesd-3111 [003] 1637.254685: fget_light <-do_sys_poll
|
||||||
|
yum-updatesd-3111 [003] 1637.254686: pipe_poll <-do_sys_poll
|
||||||
|
# echo -1 > /debug/tracing/set_ftrace_pid
|
||||||
|
# cat /debug/tracing/trace |head
|
||||||
|
# tracer: function
|
||||||
|
#
|
||||||
|
# TASK-PID CPU# TIMESTAMP FUNCTION
|
||||||
|
# | | | | |
|
||||||
|
##### CPU 3 buffer started ####
|
||||||
|
yum-updatesd-3111 [003] 1701.957688: free_poll_entry <-poll_freewait
|
||||||
|
yum-updatesd-3111 [003] 1701.957689: remove_wait_queue <-free_poll_entry
|
||||||
|
yum-updatesd-3111 [003] 1701.957691: fput <-free_poll_entry
|
||||||
|
yum-updatesd-3111 [003] 1701.957692: audit_syscall_exit <-sysret_audit
|
||||||
|
yum-updatesd-3111 [003] 1701.957693: path_put <-audit_syscall_exit
|
||||||
|
|
||||||
|
If you want to trace a function when executing, you could use
|
||||||
|
something like this simple program:
|
||||||
|
|
||||||
|
#include <stdio.h>
|
||||||
|
#include <stdlib.h>
|
||||||
|
#include <sys/types.h>
|
||||||
|
#include <sys/stat.h>
|
||||||
|
#include <fcntl.h>
|
||||||
|
#include <unistd.h>
|
||||||
|
|
||||||
|
int main (int argc, char **argv)
|
||||||
|
{
|
||||||
|
if (argc < 1)
|
||||||
|
exit(-1);
|
||||||
|
|
||||||
|
if (fork() > 0) {
|
||||||
|
int fd, ffd;
|
||||||
|
char line[64];
|
||||||
|
int s;
|
||||||
|
|
||||||
|
ffd = open("/debug/tracing/current_tracer", O_WRONLY);
|
||||||
|
if (ffd < 0)
|
||||||
|
exit(-1);
|
||||||
|
write(ffd, "nop", 3);
|
||||||
|
|
||||||
|
fd = open("/debug/tracing/set_ftrace_pid", O_WRONLY);
|
||||||
|
s = sprintf(line, "%d\n", getpid());
|
||||||
|
write(fd, line, s);
|
||||||
|
|
||||||
|
write(ffd, "function", 8);
|
||||||
|
|
||||||
|
close(fd);
|
||||||
|
close(ffd);
|
||||||
|
|
||||||
|
execvp(argv[1], argv+1);
|
||||||
|
}
|
||||||
|
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
|
|
||||||
dynamic ftrace
|
dynamic ftrace
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
|
@ -1158,7 +1251,11 @@ These are the only wild cards which are supported.
|
||||||
|
|
||||||
<match>*<match> will not work.
|
<match>*<match> will not work.
|
||||||
|
|
||||||
# echo hrtimer_* > /debug/tracing/set_ftrace_filter
|
Note: It is better to use quotes to enclose the wild cards, otherwise
|
||||||
|
the shell may expand the parameters into names of files in the local
|
||||||
|
directory.
|
||||||
|
|
||||||
|
# echo 'hrtimer_*' > /debug/tracing/set_ftrace_filter
|
||||||
|
|
||||||
Produces:
|
Produces:
|
||||||
|
|
||||||
|
@ -1213,7 +1310,7 @@ Again, now we want to append.
|
||||||
# echo sys_nanosleep > /debug/tracing/set_ftrace_filter
|
# echo sys_nanosleep > /debug/tracing/set_ftrace_filter
|
||||||
# cat /debug/tracing/set_ftrace_filter
|
# cat /debug/tracing/set_ftrace_filter
|
||||||
sys_nanosleep
|
sys_nanosleep
|
||||||
# echo hrtimer_* >> /debug/tracing/set_ftrace_filter
|
# echo 'hrtimer_*' >> /debug/tracing/set_ftrace_filter
|
||||||
# cat /debug/tracing/set_ftrace_filter
|
# cat /debug/tracing/set_ftrace_filter
|
||||||
hrtimer_run_queues
|
hrtimer_run_queues
|
||||||
hrtimer_run_pending
|
hrtimer_run_pending
|
||||||
|
@ -1299,41 +1396,29 @@ trace entries
|
||||||
-------------
|
-------------
|
||||||
|
|
||||||
Having too much or not enough data can be troublesome in diagnosing
|
Having too much or not enough data can be troublesome in diagnosing
|
||||||
an issue in the kernel. The file trace_entries is used to modify
|
an issue in the kernel. The file buffer_size_kb is used to modify
|
||||||
the size of the internal trace buffers. The number listed
|
the size of the internal trace buffers. The number listed
|
||||||
is the number of entries that can be recorded per CPU. To know
|
is the number of entries that can be recorded per CPU. To know
|
||||||
the full size, multiply the number of possible CPUS with the
|
the full size, multiply the number of possible CPUS with the
|
||||||
number of entries.
|
number of entries.
|
||||||
|
|
||||||
# cat /debug/tracing/trace_entries
|
# cat /debug/tracing/buffer_size_kb
|
||||||
65620
|
1408 (units kilobytes)
|
||||||
|
|
||||||
Note, to modify this, you must have tracing completely disabled. To do that,
|
Note, to modify this, you must have tracing completely disabled. To do that,
|
||||||
echo "nop" into the current_tracer. If the current_tracer is not set
|
echo "nop" into the current_tracer. If the current_tracer is not set
|
||||||
to "nop", an EINVAL error will be returned.
|
to "nop", an EINVAL error will be returned.
|
||||||
|
|
||||||
# echo nop > /debug/tracing/current_tracer
|
# echo nop > /debug/tracing/current_tracer
|
||||||
# echo 100000 > /debug/tracing/trace_entries
|
# echo 10000 > /debug/tracing/buffer_size_kb
|
||||||
# cat /debug/tracing/trace_entries
|
# cat /debug/tracing/buffer_size_kb
|
||||||
100045
|
10000 (units kilobytes)
|
||||||
|
|
||||||
|
|
||||||
Notice that we echoed in 100,000 but the size is 100,045. The entries
|
|
||||||
are held in individual pages. It allocates the number of pages it takes
|
|
||||||
to fulfill the request. If more entries may fit on the last page
|
|
||||||
then they will be added.
|
|
||||||
|
|
||||||
# echo 1 > /debug/tracing/trace_entries
|
|
||||||
# cat /debug/tracing/trace_entries
|
|
||||||
85
|
|
||||||
|
|
||||||
This shows us that 85 entries can fit in a single page.
|
|
||||||
|
|
||||||
The number of pages which will be allocated is limited to a percentage
|
The number of pages which will be allocated is limited to a percentage
|
||||||
of available memory. Allocating too much will produce an error.
|
of available memory. Allocating too much will produce an error.
|
||||||
|
|
||||||
# echo 1000000000000 > /debug/tracing/trace_entries
|
# echo 1000000000000 > /debug/tracing/buffer_size_kb
|
||||||
-bash: echo: write error: Cannot allocate memory
|
-bash: echo: write error: Cannot allocate memory
|
||||||
# cat /debug/tracing/trace_entries
|
# cat /debug/tracing/buffer_size_kb
|
||||||
85
|
85
|
||||||
|
|
||||||
|
|
|
@ -74,7 +74,7 @@ a sensor.
|
||||||
Notice that some banks have both a read and a write address this is how the
|
Notice that some banks have both a read and a write address this is how the
|
||||||
uGuru determines if a read from or a write to the bank is taking place, thus
|
uGuru determines if a read from or a write to the bank is taking place, thus
|
||||||
when reading you should always use the read address and when writing the
|
when reading you should always use the read address and when writing the
|
||||||
write address. The write address is always one (1) more then the read address.
|
write address. The write address is always one (1) more than the read address.
|
||||||
|
|
||||||
|
|
||||||
uGuru ready
|
uGuru ready
|
||||||
|
@ -121,7 +121,7 @@ Once all bytes have been read data will hold 0x09, but there is no reason to
|
||||||
test for this. Notice that the number of bytes is bank address dependent see
|
test for this. Notice that the number of bytes is bank address dependent see
|
||||||
above and below.
|
above and below.
|
||||||
|
|
||||||
After completing a successfull read it is advised to put the uGuru back in
|
After completing a successful read it is advised to put the uGuru back in
|
||||||
ready mode, so that it is ready for the next read / write cycle. This way
|
ready mode, so that it is ready for the next read / write cycle. This way
|
||||||
if your program / driver is unloaded and later loaded again the detection
|
if your program / driver is unloaded and later loaded again the detection
|
||||||
algorithm described above will still work.
|
algorithm described above will still work.
|
||||||
|
@ -141,7 +141,7 @@ don't ask why this is the way it is.
|
||||||
|
|
||||||
Once DATA holds 0x01 read CMD it should hold 0xAC now.
|
Once DATA holds 0x01 read CMD it should hold 0xAC now.
|
||||||
|
|
||||||
After completing a successfull write it is advised to put the uGuru back in
|
After completing a successful write it is advised to put the uGuru back in
|
||||||
ready mode, so that it is ready for the next read / write cycle. This way
|
ready mode, so that it is ready for the next read / write cycle. This way
|
||||||
if your program / driver is unloaded and later loaded again the detection
|
if your program / driver is unloaded and later loaded again the detection
|
||||||
algorithm described above will still work.
|
algorithm described above will still work.
|
||||||
|
@ -224,7 +224,7 @@ Bit 3: Beep if alarm (RW)
|
||||||
Bit 4: 1 if alarm cause measured temp is over the warning threshold (R)
|
Bit 4: 1 if alarm cause measured temp is over the warning threshold (R)
|
||||||
Bit 5: 1 if alarm cause measured volt is over the max threshold (R)
|
Bit 5: 1 if alarm cause measured volt is over the max threshold (R)
|
||||||
Bit 6: 1 if alarm cause measured volt is under the min threshold (R)
|
Bit 6: 1 if alarm cause measured volt is under the min threshold (R)
|
||||||
Bit 7: Volt sensor: Shutdown if alarm persist for more then 4 seconds (RW)
|
Bit 7: Volt sensor: Shutdown if alarm persist for more than 4 seconds (RW)
|
||||||
Temp sensor: Shutdown if temp is over the shutdown threshold (RW)
|
Temp sensor: Shutdown if temp is over the shutdown threshold (RW)
|
||||||
|
|
||||||
* This bit is only honored/used by the uGuru if a temp sensor is connected
|
* This bit is only honored/used by the uGuru if a temp sensor is connected
|
||||||
|
@ -293,7 +293,7 @@ Byte 0:
|
||||||
Alarm behaviour for the selected sensor. A 1 enables the described behaviour.
|
Alarm behaviour for the selected sensor. A 1 enables the described behaviour.
|
||||||
Bit 0: Give an alarm if measured rpm is under the min threshold (RW)
|
Bit 0: Give an alarm if measured rpm is under the min threshold (RW)
|
||||||
Bit 3: Beep if alarm (RW)
|
Bit 3: Beep if alarm (RW)
|
||||||
Bit 7: Shutdown if alarm persist for more then 4 seconds (RW)
|
Bit 7: Shutdown if alarm persist for more than 4 seconds (RW)
|
||||||
|
|
||||||
Byte 1:
|
Byte 1:
|
||||||
min threshold (scale as bank 0x26)
|
min threshold (scale as bank 0x26)
|
||||||
|
|
|
@ -31,15 +31,11 @@ Each of the measured inputs (temperature, fan speed) has corresponding high/low
|
||||||
limit values. The ADT7470 will signal an ALARM if any measured value exceeds
|
limit values. The ADT7470 will signal an ALARM if any measured value exceeds
|
||||||
either limit.
|
either limit.
|
||||||
|
|
||||||
The ADT7470 DOES NOT sample all inputs continuously. A single pin on the
|
The ADT7470 samples all inputs continuously. A kernel thread is started up for
|
||||||
ADT7470 is connected to a multitude of thermal diodes, but the chip must be
|
the purpose of periodically querying the temperature sensors, thus allowing the
|
||||||
instructed explicitly to read the multitude of diodes. If you want to use
|
automatic fan pwm control to set the fan speed. The driver will not read the
|
||||||
automatic fan control mode, you must manually read any of the temperature
|
registers more often than once every 5 seconds. Further, configuration data is
|
||||||
sensors or the fan control algorithm will not run. The chip WILL NOT DO THIS
|
only read once per minute.
|
||||||
AUTOMATICALLY; this must be done from userspace. This may be a bug in the chip
|
|
||||||
design, given that many other AD chips take care of this. The driver will not
|
|
||||||
read the registers more often than once every 5 seconds. Further,
|
|
||||||
configuration data is only read once per minute.
|
|
||||||
|
|
||||||
Special Features
|
Special Features
|
||||||
----------------
|
----------------
|
||||||
|
@ -72,5 +68,6 @@ pwm#_auto_point2_temp.
|
||||||
Notes
|
Notes
|
||||||
-----
|
-----
|
||||||
|
|
||||||
As stated above, the temperature inputs must be read periodically from
|
The temperature inputs no longer need to be read periodically from userspace in
|
||||||
userspace in order for the automatic pwm algorithm to run.
|
order for the automatic pwm algorithm to run. This was the case for earlier
|
||||||
|
versions of the driver.
|
||||||
|
|
|
@ -0,0 +1,87 @@
|
||||||
|
This describes the interface for the ADT7475 driver:
|
||||||
|
|
||||||
|
(there are 4 fans, numbered fan1 to fan4):
|
||||||
|
|
||||||
|
fanX_input Read the current speed of the fan (in RPMs)
|
||||||
|
fanX_min Read/write the minimum speed of the fan. Dropping
|
||||||
|
below this sets an alarm.
|
||||||
|
|
||||||
|
(there are three PWMs, numbered pwm1 to pwm3):
|
||||||
|
|
||||||
|
pwmX Read/write the current duty cycle of the PWM. Writes
|
||||||
|
only have effect when auto mode is turned off (see
|
||||||
|
below). Range is 0 - 255.
|
||||||
|
|
||||||
|
pwmX_enable Fan speed control method:
|
||||||
|
|
||||||
|
0 - No control (fan at full speed)
|
||||||
|
1 - Manual fan speed control (using pwm[1-*])
|
||||||
|
2 - Automatic fan speed control
|
||||||
|
|
||||||
|
pwmX_auto_channels_temp Select which channels affect this PWM
|
||||||
|
|
||||||
|
1 - TEMP1 controls PWM
|
||||||
|
2 - TEMP2 controls PWM
|
||||||
|
4 - TEMP3 controls PWM
|
||||||
|
6 - TEMP2 and TEMP3 control PWM
|
||||||
|
7 - All three inputs control PWM
|
||||||
|
|
||||||
|
pwmX_freq Read/write the PWM frequency in Hz. The number
|
||||||
|
should be one of the following:
|
||||||
|
|
||||||
|
11 Hz
|
||||||
|
14 Hz
|
||||||
|
22 Hz
|
||||||
|
29 Hz
|
||||||
|
35 Hz
|
||||||
|
44 Hz
|
||||||
|
58 Hz
|
||||||
|
88 Hz
|
||||||
|
|
||||||
|
pwmX_auto_point1_pwm Read/write the minimum PWM duty cycle in automatic mode
|
||||||
|
|
||||||
|
pwmX_auto_point2_pwm Read/write the maximum PWM duty cycle in automatic mode
|
||||||
|
|
||||||
|
(there are three temperature settings numbered temp1 to temp3):
|
||||||
|
|
||||||
|
tempX_input Read the current temperature. The value is in milli
|
||||||
|
degrees of Celsius.
|
||||||
|
|
||||||
|
tempX_max Read/write the upper temperature limit - exceeding this
|
||||||
|
will cause an alarm.
|
||||||
|
|
||||||
|
tempX_min Read/write the lower temperature limit - exceeding this
|
||||||
|
will cause an alarm.
|
||||||
|
|
||||||
|
tempX_offset Read/write the temperature adjustment offset
|
||||||
|
|
||||||
|
tempX_crit Read/write the THERM limit for remote1.
|
||||||
|
|
||||||
|
tempX_crit_hyst Set the temperature value below crit where the
|
||||||
|
fans will stay on - this helps drive the temperature
|
||||||
|
low enough so it doesn't stay near the edge and
|
||||||
|
cause THERM to keep tripping.
|
||||||
|
|
||||||
|
tempX_auto_point1_temp Read/write the minimum temperature where the fans will
|
||||||
|
turn on in automatic mode.
|
||||||
|
|
||||||
|
tempX_auto_point2_temp Read/write the maximum temperature over which the fans
|
||||||
|
will run in automatic mode. tempX_auto_point1_temp
|
||||||
|
and tempX_auto_point2_temp together define the
|
||||||
|
range of automatic control.
|
||||||
|
|
||||||
|
tempX_alarm Read a 1 if the max/min alarm is set
|
||||||
|
tempX_fault Read a 1 if either temp1 or temp3 diode has a fault
|
||||||
|
|
||||||
|
(There are two voltage settings, in1 and in2):
|
||||||
|
|
||||||
|
inX_input Read the current voltage on VCC. Value is in
|
||||||
|
millivolts.
|
||||||
|
|
||||||
|
inX_min read/write the minimum voltage limit.
|
||||||
|
Dropping below this causes an alarm.
|
||||||
|
|
||||||
|
inX_max read/write the maximum voltage limit.
|
||||||
|
Exceeding this causes an alarm.
|
||||||
|
|
||||||
|
inX_alarm Read a 1 if the max/min alarm is set.
|
|
@ -0,0 +1,89 @@
|
||||||
|
Kernel driver f71882fg
|
||||||
|
======================
|
||||||
|
|
||||||
|
Supported chips:
|
||||||
|
* Fintek F71882FG and F71883FG
|
||||||
|
Prefix: 'f71882fg'
|
||||||
|
Addresses scanned: none, address read from Super I/O config space
|
||||||
|
Datasheet: Available from the Fintek website
|
||||||
|
* Fintek F71862FG and F71863FG
|
||||||
|
Prefix: 'f71862fg'
|
||||||
|
Addresses scanned: none, address read from Super I/O config space
|
||||||
|
Datasheet: Available from the Fintek website
|
||||||
|
* Fintek F8000
|
||||||
|
Prefix: 'f8000'
|
||||||
|
Addresses scanned: none, address read from Super I/O config space
|
||||||
|
Datasheet: Not public
|
||||||
|
|
||||||
|
Author: Hans de Goede <hdegoede@redhat.com>
|
||||||
|
|
||||||
|
|
||||||
|
Description
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Fintek F718xxFG/F8000 Super I/O chips include complete hardware monitoring
|
||||||
|
capabilities. They can monitor up to 9 voltages (3 for the F8000), 4 fans and
|
||||||
|
3 temperature sensors.
|
||||||
|
|
||||||
|
These chips also have fan controlling features, using either DC or PWM, in
|
||||||
|
three different modes (one manual, two automatic).
|
||||||
|
|
||||||
|
The driver assumes that no more than one chip is present, which seems
|
||||||
|
reasonable.
|
||||||
|
|
||||||
|
|
||||||
|
Monitoring
|
||||||
|
----------
|
||||||
|
|
||||||
|
The Voltage, Fan and Temperature Monitoring uses the standard sysfs
|
||||||
|
interface as documented in sysfs-interface, without any exceptions.
|
||||||
|
|
||||||
|
|
||||||
|
Fan Control
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Both PWM (pulse-width modulation) and DC fan speed control methods are
|
||||||
|
supported. The right one to use depends on external circuitry on the
|
||||||
|
motherboard, so the driver assumes that the BIOS set the method
|
||||||
|
properly.
|
||||||
|
|
||||||
|
There are 2 modes to specify the speed of the fan, PWM duty cycle (or DC
|
||||||
|
voltage) mode, where 0-100% duty cycle (0-100% of 12V) is specified. And RPM
|
||||||
|
mode where the actual RPM of the fan (as measured) is controlled and the speed
|
||||||
|
gets specified as 0-100% of the fan#_full_speed file.
|
||||||
|
|
||||||
|
Since both modes work in a 0-100% (mapped to 0-255) scale, there isn't a
|
||||||
|
whole lot of a difference when modifying fan control settings. The only
|
||||||
|
important difference is that in RPM mode the 0-100% controls the fan speed
|
||||||
|
between 0-100% of fan#_full_speed. It is assumed that if the BIOS programs
|
||||||
|
RPM mode, it will also set fan#_full_speed properly, if it does not then
|
||||||
|
fan control will not work properly, unless you set a sane fan#_full_speed
|
||||||
|
value yourself.
|
||||||
|
|
||||||
|
Switching between these modes requires re-initializing a whole bunch of
|
||||||
|
registers, so the mode which the BIOS has set is kept. The mode is
|
||||||
|
printed when loading the driver.
|
||||||
|
|
||||||
|
Three different fan control modes are supported; the mode number is written
|
||||||
|
to the pwm#_enable file. Note that not all modes are supported on all
|
||||||
|
chips, and some modes may only be available in RPM / PWM mode on the F8000.
|
||||||
|
Writing an unsupported mode will result in an invalid parameter error.
|
||||||
|
|
||||||
|
* 1: Manual mode
|
||||||
|
You ask for a specific PWM duty cycle / DC voltage or a specific % of
|
||||||
|
fan#_full_speed by writing to the pwm# file. This mode is only
|
||||||
|
available on the F8000 if the fan channel is in RPM mode.
|
||||||
|
|
||||||
|
* 2: Normal auto mode
|
||||||
|
You can define a number of temperature/fan speed trip points, which % the
|
||||||
|
fan should run at at this temp and which temp a fan should follow using the
|
||||||
|
standard sysfs interface. The number and type of trip points is chip
|
||||||
|
depended, see which files are available in sysfs.
|
||||||
|
Fan/PWM channel 3 of the F8000 is always in this mode!
|
||||||
|
|
||||||
|
* 3: Thermostat mode (Only available on the F8000 when in duty cycle mode)
|
||||||
|
The fan speed is regulated to keep the temp the fan is mapped to between
|
||||||
|
temp#_auto_point2_temp and temp#_auto_point3_temp.
|
||||||
|
|
||||||
|
Both of the automatic modes require that pwm1 corresponds to fan1, pwm2 to
|
||||||
|
fan2 and pwm3 to fan3.
|
|
@ -26,6 +26,10 @@ Supported chips:
|
||||||
Datasheet: Publicly available at the ITE website
|
Datasheet: Publicly available at the ITE website
|
||||||
http://www.ite.com.tw/product_info/file/pc/IT8718F_V0.2.zip
|
http://www.ite.com.tw/product_info/file/pc/IT8718F_V0.2.zip
|
||||||
http://www.ite.com.tw/product_info/file/pc/IT8718F_V0%203_(for%20C%20version).zip
|
http://www.ite.com.tw/product_info/file/pc/IT8718F_V0%203_(for%20C%20version).zip
|
||||||
|
* IT8720F
|
||||||
|
Prefix: 'it8720'
|
||||||
|
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||||
|
Datasheet: Not yet publicly available.
|
||||||
* SiS950 [clone of IT8705F]
|
* SiS950 [clone of IT8705F]
|
||||||
Prefix: 'it87'
|
Prefix: 'it87'
|
||||||
Addresses scanned: from Super I/O config space (8 I/O ports)
|
Addresses scanned: from Super I/O config space (8 I/O ports)
|
||||||
|
@ -71,7 +75,7 @@ Description
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
This driver implements support for the IT8705F, IT8712F, IT8716F,
|
This driver implements support for the IT8705F, IT8712F, IT8716F,
|
||||||
IT8718F, IT8726F and SiS950 chips.
|
IT8718F, IT8720F, IT8726F and SiS950 chips.
|
||||||
|
|
||||||
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
|
These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
|
||||||
joysticks and other miscellaneous stuff. For hardware monitoring, they
|
joysticks and other miscellaneous stuff. For hardware monitoring, they
|
||||||
|
@ -84,19 +88,19 @@ the IT8716F and late IT8712F have 6. They are shared with other functions
|
||||||
though, so the functionality may not be available on a given system.
|
though, so the functionality may not be available on a given system.
|
||||||
The driver dumbly assume it is there.
|
The driver dumbly assume it is there.
|
||||||
|
|
||||||
The IT8718F also features VID inputs (up to 8 pins) but the value is
|
The IT8718F and IT8720F also features VID inputs (up to 8 pins) but the value
|
||||||
stored in the Super-I/O configuration space. Due to technical limitations,
|
is stored in the Super-I/O configuration space. Due to technical limitations,
|
||||||
this value can currently only be read once at initialization time, so
|
this value can currently only be read once at initialization time, so
|
||||||
the driver won't notice and report changes in the VID value. The two
|
the driver won't notice and report changes in the VID value. The two
|
||||||
upper VID bits share their pins with voltage inputs (in5 and in6) so you
|
upper VID bits share their pins with voltage inputs (in5 and in6) so you
|
||||||
can't have both on a given board.
|
can't have both on a given board.
|
||||||
|
|
||||||
The IT8716F, IT8718F and later IT8712F revisions have support for
|
The IT8716F, IT8718F, IT8720F and later IT8712F revisions have support for
|
||||||
2 additional fans. The additional fans are supported by the driver.
|
2 additional fans. The additional fans are supported by the driver.
|
||||||
|
|
||||||
The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional
|
The IT8716F, IT8718F and IT8720F, and late IT8712F and IT8705F also have
|
||||||
16-bit tachometer counters for fans 1 to 3. This is better (no more fan
|
optional 16-bit tachometer counters for fans 1 to 3. This is better (no more
|
||||||
clock divider mess) but not compatible with the older chips and
|
fan clock divider mess) but not compatible with the older chips and
|
||||||
revisions. The 16-bit tachometer mode is enabled by the driver when one
|
revisions. The 16-bit tachometer mode is enabled by the driver when one
|
||||||
of the above chips is detected.
|
of the above chips is detected.
|
||||||
|
|
||||||
|
@ -122,7 +126,7 @@ zero'; this is important for negative voltage measurements. All voltage
|
||||||
inputs can measure voltages between 0 and 4.08 volts, with a resolution of
|
inputs can measure voltages between 0 and 4.08 volts, with a resolution of
|
||||||
0.016 volt. The battery voltage in8 does not have limit registers.
|
0.016 volt. The battery voltage in8 does not have limit registers.
|
||||||
|
|
||||||
The VID lines (IT8712F/IT8716F/IT8718F) encode the core voltage value:
|
The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value:
|
||||||
the voltage level your processor should work with. This is hardcoded by
|
the voltage level your processor should work with. This is hardcoded by
|
||||||
the mainboard and/or processor itself. It is a value in volts.
|
the mainboard and/or processor itself. It is a value in volts.
|
||||||
|
|
||||||
|
|
|
@ -13,18 +13,21 @@ Author:
|
||||||
Description
|
Description
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
This driver provides support for the accelerometer found in various HP laptops
|
This driver provides support for the accelerometer found in various HP
|
||||||
sporting the feature officially called "HP Mobile Data Protection System 3D" or
|
laptops sporting the feature officially called "HP Mobile Data
|
||||||
"HP 3D DriveGuard". It detect automatically laptops with this sensor. Known models
|
Protection System 3D" or "HP 3D DriveGuard". It detect automatically
|
||||||
(for now the HP 2133, nc6420, nc2510, nc8510, nc84x0, nw9440 and nx9420) will
|
laptops with this sensor. Known models (for now the HP 2133, nc6420,
|
||||||
have their axis automatically oriented on standard way (eg: you can directly
|
nc2510, nc8510, nc84x0, nw9440 and nx9420) will have their axis
|
||||||
play neverball). The accelerometer data is readable via
|
automatically oriented on standard way (eg: you can directly play
|
||||||
|
neverball). The accelerometer data is readable via
|
||||||
/sys/devices/platform/lis3lv02d.
|
/sys/devices/platform/lis3lv02d.
|
||||||
|
|
||||||
Sysfs attributes under /sys/devices/platform/lis3lv02d/:
|
Sysfs attributes under /sys/devices/platform/lis3lv02d/:
|
||||||
position - 3D position that the accelerometer reports. Format: "(x,y,z)"
|
position - 3D position that the accelerometer reports. Format: "(x,y,z)"
|
||||||
calibrate - read: values (x, y, z) that are used as the base for input class device operation.
|
calibrate - read: values (x, y, z) that are used as the base for input
|
||||||
write: forces the base to be recalibrated with the current position.
|
class device operation.
|
||||||
|
write: forces the base to be recalibrated with the current
|
||||||
|
position.
|
||||||
rate - reports the sampling rate of the accelerometer device in HZ
|
rate - reports the sampling rate of the accelerometer device in HZ
|
||||||
|
|
||||||
This driver also provides an absolute input class device, allowing
|
This driver also provides an absolute input class device, allowing
|
||||||
|
@ -39,11 +42,12 @@ the accelerometer are converted into a "standard" organisation of the axes
|
||||||
* When the laptop is horizontal the position reported is about 0 for X and Y
|
* When the laptop is horizontal the position reported is about 0 for X and Y
|
||||||
and a positive value for Z
|
and a positive value for Z
|
||||||
* If the left side is elevated, X increases (becomes positive)
|
* If the left side is elevated, X increases (becomes positive)
|
||||||
* If the front side (where the touchpad is) is elevated, Y decreases (becomes negative)
|
* If the front side (where the touchpad is) is elevated, Y decreases
|
||||||
|
(becomes negative)
|
||||||
* If the laptop is put upside-down, Z becomes negative
|
* If the laptop is put upside-down, Z becomes negative
|
||||||
|
|
||||||
If your laptop model is not recognized (cf "dmesg"), you can send an email to the
|
If your laptop model is not recognized (cf "dmesg"), you can send an
|
||||||
authors to add it to the database. When reporting a new laptop, please include
|
email to the authors to add it to the database. When reporting a new
|
||||||
the output of "dmidecode" plus the value of /sys/devices/platform/lis3lv02d/position
|
laptop, please include the output of "dmidecode" plus the value of
|
||||||
in these four cases.
|
/sys/devices/platform/lis3lv02d/position in these four cases.
|
||||||
|
|
||||||
|
|
|
@ -1,9 +1,11 @@
|
||||||
Kernel driver lm70
|
Kernel driver lm70
|
||||||
==================
|
==================
|
||||||
|
|
||||||
Supported chip:
|
Supported chips:
|
||||||
* National Semiconductor LM70
|
* National Semiconductor LM70
|
||||||
Datasheet: http://www.national.com/pf/LM/LM70.html
|
Datasheet: http://www.national.com/pf/LM/LM70.html
|
||||||
|
* Texas Instruments TMP121/TMP123
|
||||||
|
Information: http://focus.ti.com/docs/prod/folders/print/tmp121.html
|
||||||
|
|
||||||
Author:
|
Author:
|
||||||
Kaiwan N Billimoria <kaiwan@designergraphix.com>
|
Kaiwan N Billimoria <kaiwan@designergraphix.com>
|
||||||
|
@ -25,6 +27,14 @@ complement digital temperature (sent via the SIO line), is available in the
|
||||||
driver for interpretation. This driver makes use of the kernel's in-core
|
driver for interpretation. This driver makes use of the kernel's in-core
|
||||||
SPI support.
|
SPI support.
|
||||||
|
|
||||||
|
As a real (in-tree) example of this "SPI protocol driver" interfacing
|
||||||
|
with a "SPI master controller driver", see drivers/spi/spi_lm70llp.c
|
||||||
|
and its associated documentation.
|
||||||
|
|
||||||
|
The TMP121/TMP123 are very similar; main differences are 4 wire SPI inter-
|
||||||
|
face (read only) and 13-bit temperature data (0.0625 degrees celsius reso-
|
||||||
|
lution).
|
||||||
|
|
||||||
Thanks to
|
Thanks to
|
||||||
---------
|
---------
|
||||||
Jean Delvare <khali@linux-fr.org> for mentoring the hwmon-side driver
|
Jean Delvare <khali@linux-fr.org> for mentoring the hwmon-side driver
|
||||||
|
|
|
@ -164,7 +164,7 @@ configured individually according to the following options.
|
||||||
temperature. (PWM value from 0 to 255)
|
temperature. (PWM value from 0 to 255)
|
||||||
|
|
||||||
* pwm#_auto_pwm_minctl - this flags selects for temp#_auto_temp_off temperature
|
* pwm#_auto_pwm_minctl - this flags selects for temp#_auto_temp_off temperature
|
||||||
the bahaviour of fans. Write 1 to let fans spinning at
|
the behaviour of fans. Write 1 to let fans spinning at
|
||||||
pwm#_auto_pwm_min or write 0 to let them off.
|
pwm#_auto_pwm_min or write 0 to let them off.
|
||||||
|
|
||||||
NOTE: It has been reported that there is a bug in the LM85 that causes the flag
|
NOTE: It has been reported that there is a bug in the LM85 that causes the flag
|
||||||
|
|
|
@ -0,0 +1,81 @@
|
||||||
|
Kernel driver ltc4245
|
||||||
|
=====================
|
||||||
|
|
||||||
|
Supported chips:
|
||||||
|
* Linear Technology LTC4245
|
||||||
|
Prefix: 'ltc4245'
|
||||||
|
Addresses scanned: 0x20-0x3f
|
||||||
|
Datasheet:
|
||||||
|
http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1003,C1006,C1140,P19392,D13517
|
||||||
|
|
||||||
|
Author: Ira W. Snyder <iws@ovro.caltech.edu>
|
||||||
|
|
||||||
|
|
||||||
|
Description
|
||||||
|
-----------
|
||||||
|
|
||||||
|
The LTC4245 controller allows a board to be safely inserted and removed
|
||||||
|
from a live backplane in multiple supply systems such as CompactPCI and
|
||||||
|
PCI Express.
|
||||||
|
|
||||||
|
|
||||||
|
Usage Notes
|
||||||
|
-----------
|
||||||
|
|
||||||
|
This driver does not probe for LTC4245 devices, due to the fact that some
|
||||||
|
of the possible addresses are unfriendly to probing. You will need to use
|
||||||
|
the "force" parameter to tell the driver where to find the device.
|
||||||
|
|
||||||
|
Example: the following will load the driver for an LTC4245 at address 0x23
|
||||||
|
on I2C bus #1:
|
||||||
|
$ modprobe ltc4245 force=1,0x23
|
||||||
|
|
||||||
|
|
||||||
|
Sysfs entries
|
||||||
|
-------------
|
||||||
|
|
||||||
|
The LTC4245 has built-in limits for over and under current warnings. This
|
||||||
|
makes it very likely that the reference circuit will be used.
|
||||||
|
|
||||||
|
This driver uses the values in the datasheet to change the register values
|
||||||
|
into the values specified in the sysfs-interface document. The current readings
|
||||||
|
rely on the sense resistors listed in Table 2: "Sense Resistor Values".
|
||||||
|
|
||||||
|
in1_input 12v input voltage (mV)
|
||||||
|
in2_input 5v input voltage (mV)
|
||||||
|
in3_input 3v input voltage (mV)
|
||||||
|
in4_input Vee (-12v) input voltage (mV)
|
||||||
|
|
||||||
|
in1_min_alarm 12v input undervoltage alarm
|
||||||
|
in2_min_alarm 5v input undervoltage alarm
|
||||||
|
in3_min_alarm 3v input undervoltage alarm
|
||||||
|
in4_min_alarm Vee (-12v) input undervoltage alarm
|
||||||
|
|
||||||
|
curr1_input 12v current (mA)
|
||||||
|
curr2_input 5v current (mA)
|
||||||
|
curr3_input 3v current (mA)
|
||||||
|
curr4_input Vee (-12v) current (mA)
|
||||||
|
|
||||||
|
curr1_max_alarm 12v overcurrent alarm
|
||||||
|
curr2_max_alarm 5v overcurrent alarm
|
||||||
|
curr3_max_alarm 3v overcurrent alarm
|
||||||
|
curr4_max_alarm Vee (-12v) overcurrent alarm
|
||||||
|
|
||||||
|
in5_input 12v output voltage (mV)
|
||||||
|
in6_input 5v output voltage (mV)
|
||||||
|
in7_input 3v output voltage (mV)
|
||||||
|
in8_input Vee (-12v) output voltage (mV)
|
||||||
|
|
||||||
|
in5_min_alarm 12v output undervoltage alarm
|
||||||
|
in6_min_alarm 5v output undervoltage alarm
|
||||||
|
in7_min_alarm 3v output undervoltage alarm
|
||||||
|
in8_min_alarm Vee (-12v) output undervoltage alarm
|
||||||
|
|
||||||
|
in9_input GPIO #1 voltage data
|
||||||
|
in10_input GPIO #2 voltage data
|
||||||
|
in11_input GPIO #3 voltage data
|
||||||
|
|
||||||
|
power1_input 12v power usage (mW)
|
||||||
|
power2_input 5v power usage (mW)
|
||||||
|
power3_input 3v power usage (mW)
|
||||||
|
power4_input Vee (-12v) power usage (mW)
|
|
@ -11,3 +11,8 @@ unplug old device(s) and plug new device(s)
|
||||||
# echo -n "1" > /sys/class/ide_port/idex/scan
|
# echo -n "1" > /sys/class/ide_port/idex/scan
|
||||||
|
|
||||||
done
|
done
|
||||||
|
|
||||||
|
NOTE: please make sure that partitions are unmounted and that there are
|
||||||
|
no other active references to devices before doing "delete_devices" step,
|
||||||
|
also do not attempt "scan" step on devices currently in use -- otherwise
|
||||||
|
results may be unpredictable and lead to data loss if you're unlucky
|
||||||
|
|
|
@ -0,0 +1,109 @@
|
||||||
|
|
||||||
|
Walkera WK-0701 transmitter is supplied with a ready to fly Walkera
|
||||||
|
helicopters such as HM36, HM37, HM60. The walkera0701 module enables to use
|
||||||
|
this transmitter as joystick
|
||||||
|
|
||||||
|
Devel homepage and download:
|
||||||
|
http://zub.fei.tuke.sk/walkera-wk0701/
|
||||||
|
|
||||||
|
or use cogito:
|
||||||
|
cg-clone http://zub.fei.tuke.sk/GIT/walkera0701-joystick
|
||||||
|
|
||||||
|
|
||||||
|
Connecting to PC:
|
||||||
|
|
||||||
|
At back side of transmitter S-video connector can be found. Modulation
|
||||||
|
pulses from processor to HF part can be found at pin 2 of this connector,
|
||||||
|
pin 3 is GND. Between pin 3 and CPU 5k6 resistor can be found. To get
|
||||||
|
modulation pulses to PC, signal pulses must be amplified.
|
||||||
|
|
||||||
|
Cable: (walkera TX to parport)
|
||||||
|
|
||||||
|
Walkera WK-0701 TX S-VIDEO connector:
|
||||||
|
(back side of TX)
|
||||||
|
__ __ S-video: canon25
|
||||||
|
/ |_| \ pin 2 (signal) NPN parport
|
||||||
|
/ O 4 3 O \ pin 3 (GND) LED ________________ 10 ACK
|
||||||
|
( O 2 1 O ) | C
|
||||||
|
\ ___ / 2 ________________________|\|_____|/
|
||||||
|
| [___] | |/| B |\
|
||||||
|
------- 3 __________________________________|________________ 25 GND
|
||||||
|
E
|
||||||
|
|
||||||
|
|
||||||
|
I use green LED and BC109 NPN transistor.
|
||||||
|
|
||||||
|
Software:
|
||||||
|
|
||||||
|
Build kernel with walkera0701 module. Module walkera0701 need exclusive
|
||||||
|
access to parport, modules like lp must be unloaded before loading
|
||||||
|
walkera0701 module, check dmesg for error messages. Connect TX to PC by
|
||||||
|
cable and run jstest /dev/input/js0 to see values from TX. If no value can
|
||||||
|
be changed by TX "joystick", check output from /proc/interrupts. Value for
|
||||||
|
(usually irq7) parport must increase if TX is on.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Technical details:
|
||||||
|
|
||||||
|
Driver use interrupt from parport ACK input bit to measure pulse length
|
||||||
|
using hrtimers.
|
||||||
|
|
||||||
|
Frame format:
|
||||||
|
Based on walkera WK-0701 PCM Format description by Shaul Eizikovich.
|
||||||
|
(downloaded from http://www.smartpropoplus.com/Docs/Walkera_Wk-0701_PCM.pdf)
|
||||||
|
|
||||||
|
Signal pulses:
|
||||||
|
(ANALOG)
|
||||||
|
SYNC BIN OCT
|
||||||
|
+---------+ +------+
|
||||||
|
| | | |
|
||||||
|
--+ +------+ +---
|
||||||
|
|
||||||
|
Frame:
|
||||||
|
SYNC , BIN1, OCT1, BIN2, OCT2 ... BIN24, OCT24, BIN25, next frame SYNC ..
|
||||||
|
|
||||||
|
pulse length:
|
||||||
|
Binary values: Analog octal values:
|
||||||
|
|
||||||
|
288 uS Binary 0 318 uS 000
|
||||||
|
438 uS Binary 1 398 uS 001
|
||||||
|
478 uS 010
|
||||||
|
558 uS 011
|
||||||
|
638 uS 100
|
||||||
|
1306 uS SYNC 718 uS 101
|
||||||
|
798 uS 110
|
||||||
|
878 uS 111
|
||||||
|
|
||||||
|
24 bin+oct values + 1 bin value = 24*4+1 bits = 97 bits
|
||||||
|
|
||||||
|
(Warning, pulses on ACK ar inverted by transistor, irq is rised up on sync
|
||||||
|
to bin change or octal value to bin change).
|
||||||
|
|
||||||
|
Binary data representations:
|
||||||
|
|
||||||
|
One binary and octal value can be grouped to nibble. 24 nibbles + one binary
|
||||||
|
values can be sampled between sync pulses.
|
||||||
|
|
||||||
|
Values for first four channels (analog joystick values) can be found in
|
||||||
|
first 10 nibbles. Analog value is represented by one sign bit and 9 bit
|
||||||
|
absolute binary value. (10 bits per channel). Next nibble is checksum for
|
||||||
|
first ten nibbles.
|
||||||
|
|
||||||
|
Next nibbles 12 .. 21 represents four channels (not all channels can be
|
||||||
|
directly controlled from TX). Binary representations ar the same as in first
|
||||||
|
four channels. In nibbles 22 and 23 is a special magic number. Nibble 24 is
|
||||||
|
checksum for nibbles 12..23.
|
||||||
|
|
||||||
|
After last octal value for nibble 24 and next sync pulse one additional
|
||||||
|
binary value can be sampled. This bit and magic number is not used in
|
||||||
|
software driver. Some details about this magic numbers can be found in
|
||||||
|
Walkera_Wk-0701_PCM.pdf.
|
||||||
|
|
||||||
|
Checksum calculation:
|
||||||
|
|
||||||
|
Summary of octal values in nibbles must be same as octal value in checksum
|
||||||
|
nibble (only first 3 bits are used). Binary value for checksum nibble is
|
||||||
|
calculated by sum of binary values in checked nibbles + sum of octal values
|
||||||
|
in checked nibbles divided by 8. Only bit 0 of this sum is used.
|
||||||
|
|
|
@ -84,7 +84,7 @@ Code Seq# Include File Comments
|
||||||
'B' C0-FF advanced bbus
|
'B' C0-FF advanced bbus
|
||||||
<mailto:maassen@uni-freiburg.de>
|
<mailto:maassen@uni-freiburg.de>
|
||||||
'C' all linux/soundcard.h
|
'C' all linux/soundcard.h
|
||||||
'D' all asm-s390/dasd.h
|
'D' all arch/s390/include/asm/dasd.h
|
||||||
'E' all linux/input.h
|
'E' all linux/input.h
|
||||||
'F' all linux/fb.h
|
'F' all linux/fb.h
|
||||||
'H' all linux/hiddev.h
|
'H' all linux/hiddev.h
|
||||||
|
@ -97,6 +97,7 @@ Code Seq# Include File Comments
|
||||||
<http://linux01.gwdg.de/~alatham/ppdd.html>
|
<http://linux01.gwdg.de/~alatham/ppdd.html>
|
||||||
'M' all linux/soundcard.h
|
'M' all linux/soundcard.h
|
||||||
'N' 00-1F drivers/usb/scanner.h
|
'N' 00-1F drivers/usb/scanner.h
|
||||||
|
'O' 00-02 include/mtd/ubi-user.h UBI
|
||||||
'P' all linux/soundcard.h
|
'P' all linux/soundcard.h
|
||||||
'Q' all linux/soundcard.h
|
'Q' all linux/soundcard.h
|
||||||
'R' 00-1F linux/random.h
|
'R' 00-1F linux/random.h
|
||||||
|
@ -104,7 +105,7 @@ Code Seq# Include File Comments
|
||||||
'S' 80-81 scsi/scsi_ioctl.h conflict!
|
'S' 80-81 scsi/scsi_ioctl.h conflict!
|
||||||
'S' 82-FF scsi/scsi.h conflict!
|
'S' 82-FF scsi/scsi.h conflict!
|
||||||
'T' all linux/soundcard.h conflict!
|
'T' all linux/soundcard.h conflict!
|
||||||
'T' all asm-i386/ioctls.h conflict!
|
'T' all arch/x86/include/asm/ioctls.h conflict!
|
||||||
'U' 00-EF linux/drivers/usb/usb.h
|
'U' 00-EF linux/drivers/usb/usb.h
|
||||||
'V' all linux/vt.h
|
'V' all linux/vt.h
|
||||||
'W' 00-1F linux/watchdog.h conflict!
|
'W' 00-1F linux/watchdog.h conflict!
|
||||||
|
@ -119,7 +120,7 @@ Code Seq# Include File Comments
|
||||||
<mailto:natalia@nikhefk.nikhef.nl>
|
<mailto:natalia@nikhefk.nikhef.nl>
|
||||||
'c' 00-7F linux/comstats.h conflict!
|
'c' 00-7F linux/comstats.h conflict!
|
||||||
'c' 00-7F linux/coda.h conflict!
|
'c' 00-7F linux/coda.h conflict!
|
||||||
'c' 80-9F asm-s390/chsc.h
|
'c' 80-9F arch/s390/include/asm/chsc.h
|
||||||
'd' 00-FF linux/char/drm/drm/h conflict!
|
'd' 00-FF linux/char/drm/drm/h conflict!
|
||||||
'd' 00-DF linux/video_decoder.h conflict!
|
'd' 00-DF linux/video_decoder.h conflict!
|
||||||
'd' F0-FF linux/digi1.h
|
'd' F0-FF linux/digi1.h
|
||||||
|
@ -142,6 +143,9 @@ Code Seq# Include File Comments
|
||||||
'n' 00-7F linux/ncp_fs.h
|
'n' 00-7F linux/ncp_fs.h
|
||||||
'n' E0-FF video/matrox.h matroxfb
|
'n' E0-FF video/matrox.h matroxfb
|
||||||
'o' 00-1F fs/ocfs2/ocfs2_fs.h OCFS2
|
'o' 00-1F fs/ocfs2/ocfs2_fs.h OCFS2
|
||||||
|
'o' 00-03 include/mtd/ubi-user.h conflict! (OCFS2 and UBI overlaps)
|
||||||
|
'o' 40-41 include/mtd/ubi-user.h UBI
|
||||||
|
'o' 01-A1 include/linux/dvb/*.h DVB
|
||||||
'p' 00-0F linux/phantom.h conflict! (OpenHaptics needs this)
|
'p' 00-0F linux/phantom.h conflict! (OpenHaptics needs this)
|
||||||
'p' 00-3F linux/mc146818rtc.h conflict!
|
'p' 00-3F linux/mc146818rtc.h conflict!
|
||||||
'p' 40-7F linux/nvram.h
|
'p' 40-7F linux/nvram.h
|
||||||
|
@ -166,7 +170,7 @@ Code Seq# Include File Comments
|
||||||
<mailto:oe@port.de>
|
<mailto:oe@port.de>
|
||||||
0x80 00-1F linux/fb.h
|
0x80 00-1F linux/fb.h
|
||||||
0x81 00-1F linux/videotext.h
|
0x81 00-1F linux/videotext.h
|
||||||
0x89 00-06 asm-i386/sockios.h
|
0x89 00-06 arch/x86/include/asm/sockios.h
|
||||||
0x89 0B-DF linux/sockios.h
|
0x89 0B-DF linux/sockios.h
|
||||||
0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range
|
0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range
|
||||||
0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range
|
0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range
|
||||||
|
|
|
@ -1,5 +1,9 @@
|
||||||
00-INDEX
|
00-INDEX
|
||||||
- this file: info on the kernel build process
|
- this file: info on the kernel build process
|
||||||
|
kbuild.txt
|
||||||
|
- developer information on kbuild
|
||||||
|
kconfig.txt
|
||||||
|
- usage help for make *config
|
||||||
kconfig-language.txt
|
kconfig-language.txt
|
||||||
- specification of Config Language, the language in Kconfig files
|
- specification of Config Language, the language in Kconfig files
|
||||||
makefiles.txt
|
makefiles.txt
|
||||||
|
|
|
@ -0,0 +1,133 @@
|
||||||
|
Environment variables
|
||||||
|
|
||||||
|
KCPPFLAGS
|
||||||
|
--------------------------------------------------
|
||||||
|
Additional options to pass when preprocessing. The preprocessing options
|
||||||
|
will be used in all cases where kbuild do preprocessing including
|
||||||
|
building C files and assembler files.
|
||||||
|
|
||||||
|
KAFLAGS
|
||||||
|
--------------------------------------------------
|
||||||
|
Additional options to the assembler.
|
||||||
|
|
||||||
|
KCFLAGS
|
||||||
|
--------------------------------------------------
|
||||||
|
Additional options to the C compiler.
|
||||||
|
|
||||||
|
KBUILD_VERBOSE
|
||||||
|
--------------------------------------------------
|
||||||
|
Set the kbuild verbosity. Can be assinged same values as "V=...".
|
||||||
|
See make help for the full list.
|
||||||
|
Setting "V=..." takes precedence over KBUILD_VERBOSE.
|
||||||
|
|
||||||
|
KBUILD_EXTMOD
|
||||||
|
--------------------------------------------------
|
||||||
|
Set the directory to look for the kernel source when building external
|
||||||
|
modules.
|
||||||
|
The directory can be specified in several ways:
|
||||||
|
1) Use "M=..." on the command line
|
||||||
|
2) Environmnet variable KBUILD_EXTMOD
|
||||||
|
3) Environmnet variable SUBDIRS
|
||||||
|
The possibilities are listed in the order they take precedence.
|
||||||
|
Using "M=..." will always override the others.
|
||||||
|
|
||||||
|
KBUILD_OUTPUT
|
||||||
|
--------------------------------------------------
|
||||||
|
Specify the output directory when building the kernel.
|
||||||
|
The output directory can also be specificed using "O=...".
|
||||||
|
Setting "O=..." takes precedence over KBUILD_OUTPUT
|
||||||
|
|
||||||
|
ARCH
|
||||||
|
--------------------------------------------------
|
||||||
|
Set ARCH to the architecture to be built.
|
||||||
|
In most cases the name of the architecture is the same as the
|
||||||
|
directory name found in the arch/ directory.
|
||||||
|
But some architectures suach as x86 and sparc has aliases.
|
||||||
|
x86: i386 for 32 bit, x86_64 for 64 bit
|
||||||
|
sparc: sparc for 32 bit, sparc64 for 64 bit
|
||||||
|
|
||||||
|
CROSS_COMPILE
|
||||||
|
--------------------------------------------------
|
||||||
|
Specify an optional fixed part of the binutils filename.
|
||||||
|
CROSS_COMPILE can be a part of the filename or the full path.
|
||||||
|
|
||||||
|
CROSS_COMPILE is also used for ccache is some setups.
|
||||||
|
|
||||||
|
CF
|
||||||
|
--------------------------------------------------
|
||||||
|
Additional options for sparse.
|
||||||
|
CF is often used on the command-line like this:
|
||||||
|
|
||||||
|
make CF=-Wbitwise C=2
|
||||||
|
|
||||||
|
INSTALL_PATH
|
||||||
|
--------------------------------------------------
|
||||||
|
INSTALL_PATH specifies where to place the updated kernel and system map
|
||||||
|
images. Default is /boot, but you can set it to other values
|
||||||
|
|
||||||
|
|
||||||
|
MODLIB
|
||||||
|
--------------------------------------------------
|
||||||
|
Specify where to install modules.
|
||||||
|
The default value is:
|
||||||
|
|
||||||
|
$(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
|
||||||
|
|
||||||
|
The value can be overridden in which case the default value is ignored.
|
||||||
|
|
||||||
|
INSTALL_MOD_PATH
|
||||||
|
--------------------------------------------------
|
||||||
|
INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
|
||||||
|
relocations required by build roots. This is not defined in the
|
||||||
|
makefile but the argument can be passed to make if needed.
|
||||||
|
|
||||||
|
INSTALL_MOD_STRIP
|
||||||
|
--------------------------------------------------
|
||||||
|
INSTALL_MOD_STRIP, if defined, will cause modules to be
|
||||||
|
stripped after they are installed. If INSTALL_MOD_STRIP is '1', then
|
||||||
|
the default option --strip-debug will be used. Otherwise,
|
||||||
|
INSTALL_MOD_STRIP will used as the options to the strip command.
|
||||||
|
|
||||||
|
INSTALL_FW_PATH
|
||||||
|
--------------------------------------------------
|
||||||
|
INSTALL_FW_PATH specify where to install the firmware blobs.
|
||||||
|
The default value is:
|
||||||
|
|
||||||
|
$(INSTALL_MOD_PATH)/lib/firmware
|
||||||
|
|
||||||
|
The value can be overridden in which case the default value is ignored.
|
||||||
|
|
||||||
|
INSTALL_HDR_PATH
|
||||||
|
--------------------------------------------------
|
||||||
|
INSTALL_HDR_PATH specify where to install user space headers when
|
||||||
|
executing "make headers_*".
|
||||||
|
The default value is:
|
||||||
|
|
||||||
|
$(objtree)/usr
|
||||||
|
|
||||||
|
$(objtree) is the directory where output files are saved.
|
||||||
|
The output directory is often set using "O=..." on the commandline.
|
||||||
|
|
||||||
|
The value can be overridden in which case the default value is ignored.
|
||||||
|
|
||||||
|
KBUILD_MODPOST_WARN
|
||||||
|
--------------------------------------------------
|
||||||
|
KBUILD_MODPOST_WARN can be set to avoid error out in case of undefined
|
||||||
|
symbols in the final module linking stage.
|
||||||
|
|
||||||
|
KBUILD_MODPOST_FINAL
|
||||||
|
--------------------------------------------------
|
||||||
|
KBUILD_MODPOST_NOFINAL can be set to skip the final link of modules.
|
||||||
|
This is solely usefull to speed up test compiles.
|
||||||
|
|
||||||
|
KBUILD_EXTRA_SYMBOLS
|
||||||
|
--------------------------------------------------
|
||||||
|
For modules use symbols from another modules.
|
||||||
|
See more details in modules.txt.
|
||||||
|
|
||||||
|
ALLSOURCE_ARCHS
|
||||||
|
--------------------------------------------------
|
||||||
|
For tags/TAGS/cscope targets, you can specify more than one archs
|
||||||
|
to be included in the databases, separated by blankspace. e.g.
|
||||||
|
|
||||||
|
$ make ALLSOURCE_ARCHS="x86 mips arm" tags
|
|
@ -0,0 +1,188 @@
|
||||||
|
This file contains some assistance for using "make *config".
|
||||||
|
|
||||||
|
Use "make help" to list all of the possible configuration targets.
|
||||||
|
|
||||||
|
The xconfig ('qconf') and menuconfig ('mconf') programs also
|
||||||
|
have embedded help text. Be sure to check it for navigation,
|
||||||
|
search, and other general help text.
|
||||||
|
|
||||||
|
======================================================================
|
||||||
|
General
|
||||||
|
--------------------------------------------------
|
||||||
|
|
||||||
|
New kernel releases often introduce new config symbols. Often more
|
||||||
|
important, new kernel releases may rename config symbols. When
|
||||||
|
this happens, using a previously working .config file and running
|
||||||
|
"make oldconfig" won't necessarily produce a working new kernel
|
||||||
|
for you, so you may find that you need to see what NEW kernel
|
||||||
|
symbols have been introduced.
|
||||||
|
|
||||||
|
To see a list of new config symbols when using "make oldconfig", use
|
||||||
|
|
||||||
|
cp user/some/old.config .config
|
||||||
|
yes "" | make oldconfig >conf.new
|
||||||
|
|
||||||
|
and the config program will list as (NEW) any new symbols that have
|
||||||
|
unknown values. Of course, the .config file is also updated with
|
||||||
|
new (default) values, so you can use:
|
||||||
|
|
||||||
|
grep "(NEW)" conf.new
|
||||||
|
|
||||||
|
to see the new config symbols or you can 'diff' the previous and
|
||||||
|
new .config files to see the differences:
|
||||||
|
|
||||||
|
diff .config.old .config | less
|
||||||
|
|
||||||
|
(Yes, we need something better here.)
|
||||||
|
|
||||||
|
|
||||||
|
======================================================================
|
||||||
|
menuconfig
|
||||||
|
--------------------------------------------------
|
||||||
|
|
||||||
|
SEARCHING for CONFIG symbols
|
||||||
|
|
||||||
|
Searching in menuconfig:
|
||||||
|
|
||||||
|
The Search function searches for kernel configuration symbol
|
||||||
|
names, so you have to know something close to what you are
|
||||||
|
looking for.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
/hotplug
|
||||||
|
This lists all config symbols that contain "hotplug",
|
||||||
|
e.g., HOTPLUG, HOTPLUG_CPU, MEMORY_HOTPLUG.
|
||||||
|
|
||||||
|
For search help, enter / followed TAB-TAB-TAB (to highlight
|
||||||
|
<Help>) and Enter. This will tell you that you can also use
|
||||||
|
regular expressions (regexes) in the search string, so if you
|
||||||
|
are not interested in MEMORY_HOTPLUG, you could try
|
||||||
|
|
||||||
|
/^hotplug
|
||||||
|
|
||||||
|
|
||||||
|
______________________________________________________________________
|
||||||
|
Color Themes for 'menuconfig'
|
||||||
|
|
||||||
|
It is possible to select different color themes using the variable
|
||||||
|
MENUCONFIG_COLOR. To select a theme use:
|
||||||
|
|
||||||
|
make MENUCONFIG_COLOR=<theme> menuconfig
|
||||||
|
|
||||||
|
Available themes are:
|
||||||
|
mono => selects colors suitable for monochrome displays
|
||||||
|
blackbg => selects a color scheme with black background
|
||||||
|
classic => theme with blue background. The classic look
|
||||||
|
bluetitle => a LCD friendly version of classic. (default)
|
||||||
|
|
||||||
|
______________________________________________________________________
|
||||||
|
Environment variables in 'menuconfig'
|
||||||
|
|
||||||
|
KCONFIG_ALLCONFIG
|
||||||
|
--------------------------------------------------
|
||||||
|
(partially based on lkml email from/by Rob Landley, re: miniconfig)
|
||||||
|
--------------------------------------------------
|
||||||
|
The allyesconfig/allmodconfig/allnoconfig/randconfig variants can
|
||||||
|
also use the environment variable KCONFIG_ALLCONFIG as a flag or a
|
||||||
|
filename that contains config symbols that the user requires to be
|
||||||
|
set to a specific value. If KCONFIG_ALLCONFIG is used without a
|
||||||
|
filename, "make *config" checks for a file named
|
||||||
|
"all{yes/mod/no/random}.config" (corresponding to the *config command
|
||||||
|
that was used) for symbol values that are to be forced. If this file
|
||||||
|
is not found, it checks for a file named "all.config" to contain forced
|
||||||
|
values.
|
||||||
|
|
||||||
|
This enables you to create "miniature" config (miniconfig) or custom
|
||||||
|
config files containing just the config symbols that you are interested
|
||||||
|
in. Then the kernel config system generates the full .config file,
|
||||||
|
including dependencies of your miniconfig file, based on the miniconfig
|
||||||
|
file.
|
||||||
|
|
||||||
|
This 'KCONFIG_ALLCONFIG' file is a config file which contains
|
||||||
|
(usually a subset of all) preset config symbols. These variable
|
||||||
|
settings are still subject to normal dependency checks.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
KCONFIG_ALLCONFIG=custom-notebook.config make allnoconfig
|
||||||
|
or
|
||||||
|
KCONFIG_ALLCONFIG=mini.config make allnoconfig
|
||||||
|
or
|
||||||
|
make KCONFIG_ALLCONFIG=mini.config allnoconfig
|
||||||
|
|
||||||
|
These examples will disable most options (allnoconfig) but enable or
|
||||||
|
disable the options that are explicitly listed in the specified
|
||||||
|
mini-config files.
|
||||||
|
|
||||||
|
KCONFIG_NOSILENTUPDATE
|
||||||
|
--------------------------------------------------
|
||||||
|
If this variable has a non-blank value, it prevents silent kernel
|
||||||
|
config udpates (requires explicit updates).
|
||||||
|
|
||||||
|
KCONFIG_CONFIG
|
||||||
|
--------------------------------------------------
|
||||||
|
This environment variable can be used to specify a default kernel config
|
||||||
|
file name to override the default name of ".config".
|
||||||
|
|
||||||
|
KCONFIG_OVERWRITECONFIG
|
||||||
|
--------------------------------------------------
|
||||||
|
If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not
|
||||||
|
break symlinks when .config is a symlink to somewhere else.
|
||||||
|
|
||||||
|
KCONFIG_NOTIMESTAMP
|
||||||
|
--------------------------------------------------
|
||||||
|
If this environment variable exists and is non-null, the timestamp line
|
||||||
|
in generated .config files is omitted.
|
||||||
|
|
||||||
|
KCONFIG_AUTOCONFIG
|
||||||
|
--------------------------------------------------
|
||||||
|
This environment variable can be set to specify the path & name of the
|
||||||
|
"auto.conf" file. Its default value is "include/config/auto.conf".
|
||||||
|
|
||||||
|
KCONFIG_AUTOHEADER
|
||||||
|
--------------------------------------------------
|
||||||
|
This environment variable can be set to specify the path & name of the
|
||||||
|
"autoconf.h" (header) file. Its default value is "include/linux/autoconf.h".
|
||||||
|
|
||||||
|
______________________________________________________________________
|
||||||
|
menuconfig User Interface Options
|
||||||
|
----------------------------------------------------------------------
|
||||||
|
MENUCONFIG_MODE
|
||||||
|
--------------------------------------------------
|
||||||
|
This mode shows all sub-menus in one large tree.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
MENUCONFIG_MODE=single_menu make menuconfig
|
||||||
|
|
||||||
|
======================================================================
|
||||||
|
xconfig
|
||||||
|
--------------------------------------------------
|
||||||
|
|
||||||
|
Searching in xconfig:
|
||||||
|
|
||||||
|
The Search function searches for kernel configuration symbol
|
||||||
|
names, so you have to know something close to what you are
|
||||||
|
looking for.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
Ctrl-F hotplug
|
||||||
|
or
|
||||||
|
Menu: File, Search, hotplug
|
||||||
|
|
||||||
|
lists all config symbol entries that contain "hotplug" in
|
||||||
|
the symbol name. In this Search dialog, you may change the
|
||||||
|
config setting for any of the entries that are not grayed out.
|
||||||
|
You can also enter a different search string without having
|
||||||
|
to return to the main menu.
|
||||||
|
|
||||||
|
|
||||||
|
======================================================================
|
||||||
|
gconfig
|
||||||
|
--------------------------------------------------
|
||||||
|
|
||||||
|
Searching in gconfig:
|
||||||
|
|
||||||
|
None (gconfig isn't maintained as well as xconfig or menuconfig);
|
||||||
|
however, gconfig does have a few more viewing choices than
|
||||||
|
xconfig does.
|
||||||
|
|
||||||
|
###
|
|
@ -383,6 +383,20 @@ more details, with real examples.
|
||||||
to prerequisites are referenced with $(src) (because they are not
|
to prerequisites are referenced with $(src) (because they are not
|
||||||
generated files).
|
generated files).
|
||||||
|
|
||||||
|
$(kecho)
|
||||||
|
echoing information to user in a rule is often a good practice
|
||||||
|
but when execution "make -s" one does not expect to see any output
|
||||||
|
except for warnings/errors.
|
||||||
|
To support this kbuild define $(kecho) which will echo out the
|
||||||
|
text following $(kecho) to stdout except if "make -s" is used.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
#arch/blackfin/boot/Makefile
|
||||||
|
$(obj)/vmImage: $(obj)/vmlinux.gz
|
||||||
|
$(call if_changed,uimage)
|
||||||
|
@$(kecho) 'Kernel: $@ is ready'
|
||||||
|
|
||||||
|
|
||||||
--- 3.11 $(CC) support functions
|
--- 3.11 $(CC) support functions
|
||||||
|
|
||||||
The kernel may be built with several different versions of
|
The kernel may be built with several different versions of
|
||||||
|
|
|
@ -253,7 +253,7 @@ following files:
|
||||||
|
|
||||||
# Module specific targets
|
# Module specific targets
|
||||||
genbin:
|
genbin:
|
||||||
echo "X" > 8123_bin_shipped
|
echo "X" > 8123_bin.o_shipped
|
||||||
|
|
||||||
|
|
||||||
In example 2, we are down to two fairly simple files and for simple
|
In example 2, we are down to two fairly simple files and for simple
|
||||||
|
@ -279,7 +279,7 @@ following files:
|
||||||
|
|
||||||
# Module specific targets
|
# Module specific targets
|
||||||
genbin:
|
genbin:
|
||||||
echo "X" > 8123_bin_shipped
|
echo "X" > 8123_bin.o_shipped
|
||||||
|
|
||||||
endif
|
endif
|
||||||
|
|
||||||
|
|
|
@ -71,6 +71,11 @@ The @argument descriptions must begin on the very next line following
|
||||||
this opening short function description line, with no intervening
|
this opening short function description line, with no intervening
|
||||||
empty comment lines.
|
empty comment lines.
|
||||||
|
|
||||||
|
If a function parameter is "..." (varargs), it should be listed in
|
||||||
|
kernel-doc notation as:
|
||||||
|
* @...: description
|
||||||
|
|
||||||
|
|
||||||
Example kernel-doc data structure comment.
|
Example kernel-doc data structure comment.
|
||||||
|
|
||||||
/**
|
/**
|
||||||
|
@ -282,6 +287,32 @@ struct my_struct {
|
||||||
};
|
};
|
||||||
|
|
||||||
|
|
||||||
|
Including documentation blocks in source files
|
||||||
|
----------------------------------------------
|
||||||
|
|
||||||
|
To facilitate having source code and comments close together, you can
|
||||||
|
include kernel-doc documentation blocks that are free-form comments
|
||||||
|
instead of being kernel-doc for functions, structures, unions,
|
||||||
|
enums, or typedefs. This could be used for something like a
|
||||||
|
theory of operation for a driver or library code, for example.
|
||||||
|
|
||||||
|
This is done by using a DOC: section keyword with a section title. E.g.:
|
||||||
|
|
||||||
|
/**
|
||||||
|
* DOC: Theory of Operation
|
||||||
|
*
|
||||||
|
* The whizbang foobar is a dilly of a gizmo. It can do whatever you
|
||||||
|
* want it to do, at any time. It reads your mind. Here's how it works.
|
||||||
|
*
|
||||||
|
* foo bar splat
|
||||||
|
*
|
||||||
|
* The only drawback to this gizmo is that is can sometimes damage
|
||||||
|
* hardware, software, or its subject(s).
|
||||||
|
*/
|
||||||
|
|
||||||
|
DOC: sections are used in SGML templates files as indicated below.
|
||||||
|
|
||||||
|
|
||||||
How to make new SGML template files
|
How to make new SGML template files
|
||||||
-----------------------------------
|
-----------------------------------
|
||||||
|
|
||||||
|
@ -302,6 +333,9 @@ exported using EXPORT_SYMBOL.
|
||||||
!F<filename> <function [functions...]> is replaced by the
|
!F<filename> <function [functions...]> is replaced by the
|
||||||
documentation, in <filename>, for the functions listed.
|
documentation, in <filename>, for the functions listed.
|
||||||
|
|
||||||
|
!P<filename> <section title> is replaced by the contents of the DOC:
|
||||||
|
section titled <section title> from <filename>.
|
||||||
|
Spaces are allowed in <section title>; do not quote the <section title>.
|
||||||
|
|
||||||
Tim.
|
Tim.
|
||||||
*/ <twaugh@redhat.com>
|
*/ <twaugh@redhat.com>
|
||||||
|
|
|
@ -89,7 +89,9 @@ parameter is applicable:
|
||||||
SPARC Sparc architecture is enabled.
|
SPARC Sparc architecture is enabled.
|
||||||
SWSUSP Software suspend (hibernation) is enabled.
|
SWSUSP Software suspend (hibernation) is enabled.
|
||||||
SUSPEND System suspend states are enabled.
|
SUSPEND System suspend states are enabled.
|
||||||
|
FTRACE Function tracing enabled.
|
||||||
TS Appropriate touchscreen support is enabled.
|
TS Appropriate touchscreen support is enabled.
|
||||||
|
UMS USB Mass Storage support is enabled.
|
||||||
USB USB support is enabled.
|
USB USB support is enabled.
|
||||||
USBHID USB Human Interface Device support is enabled.
|
USBHID USB Human Interface Device support is enabled.
|
||||||
V4L Video For Linux support is enabled.
|
V4L Video For Linux support is enabled.
|
||||||
|
@ -139,6 +141,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
ht -- run only enough ACPI to enable Hyper Threading
|
ht -- run only enough ACPI to enable Hyper Threading
|
||||||
strict -- Be less tolerant of platforms that are not
|
strict -- Be less tolerant of platforms that are not
|
||||||
strictly ACPI specification compliant.
|
strictly ACPI specification compliant.
|
||||||
|
rsdt -- prefer RSDT over (default) XSDT
|
||||||
|
|
||||||
See also Documentation/power/pm.txt, pci=noacpi
|
See also Documentation/power/pm.txt, pci=noacpi
|
||||||
|
|
||||||
|
@ -149,16 +152,20 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
default: 0
|
default: 0
|
||||||
|
|
||||||
acpi_sleep= [HW,ACPI] Sleep options
|
acpi_sleep= [HW,ACPI] Sleep options
|
||||||
Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig, old_ordering }
|
Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig,
|
||||||
See Documentation/power/video.txt for s3_bios and s3_mode.
|
old_ordering, s4_nonvs }
|
||||||
|
See Documentation/power/video.txt for information on
|
||||||
|
s3_bios and s3_mode.
|
||||||
s3_beep is for debugging; it makes the PC's speaker beep
|
s3_beep is for debugging; it makes the PC's speaker beep
|
||||||
as soon as the kernel's real-mode entry point is called.
|
as soon as the kernel's real-mode entry point is called.
|
||||||
s4_nohwsig prevents ACPI hardware signature from being
|
s4_nohwsig prevents ACPI hardware signature from being
|
||||||
used during resume from hibernation.
|
used during resume from hibernation.
|
||||||
old_ordering causes the ACPI 1.0 ordering of the _PTS
|
old_ordering causes the ACPI 1.0 ordering of the _PTS
|
||||||
control method, wrt putting devices into low power
|
control method, with respect to putting devices into
|
||||||
states, to be enforced (the ACPI 2.0 ordering of _PTS is
|
low power states, to be enforced (the ACPI 2.0 ordering
|
||||||
used by default).
|
of _PTS is used by default).
|
||||||
|
s4_nonvs prevents the kernel from saving/restoring the
|
||||||
|
ACPI NVS memory during hibernation.
|
||||||
|
|
||||||
acpi_sci= [HW,ACPI] ACPI System Control Interrupt trigger mode
|
acpi_sci= [HW,ACPI] ACPI System Control Interrupt trigger mode
|
||||||
Format: { level | edge | high | low }
|
Format: { level | edge | high | low }
|
||||||
|
@ -193,7 +200,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
acpi_skip_timer_override [HW,ACPI]
|
acpi_skip_timer_override [HW,ACPI]
|
||||||
Recognize and ignore IRQ0/pin2 Interrupt Override.
|
Recognize and ignore IRQ0/pin2 Interrupt Override.
|
||||||
For broken nForce2 BIOS resulting in XT-PIC timer.
|
For broken nForce2 BIOS resulting in XT-PIC timer.
|
||||||
acpi_use_timer_override [HW,ACPI}
|
acpi_use_timer_override [HW,ACPI]
|
||||||
Use timer override. For some broken Nvidia NF5 boards
|
Use timer override. For some broken Nvidia NF5 boards
|
||||||
that require a timer override, but don't have
|
that require a timer override, but don't have
|
||||||
HPET
|
HPET
|
||||||
|
@ -468,8 +475,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
|
|
||||||
clearcpuid=BITNUM [X86]
|
clearcpuid=BITNUM [X86]
|
||||||
Disable CPUID feature X for the kernel. See
|
Disable CPUID feature X for the kernel. See
|
||||||
include/asm-x86/cpufeature.h for the valid bit numbers.
|
arch/x86/include/asm/cpufeature.h for the valid bit
|
||||||
Note the Linux specific bits are not necessarily
|
numbers. Note the Linux specific bits are not necessarily
|
||||||
stable over kernel options, but the vendor specific
|
stable over kernel options, but the vendor specific
|
||||||
ones should be.
|
ones should be.
|
||||||
Also note that user programs calling CPUID directly
|
Also note that user programs calling CPUID directly
|
||||||
|
@ -550,6 +557,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
not work reliably with all consoles, but is known
|
not work reliably with all consoles, but is known
|
||||||
to work with serial and VGA consoles.
|
to work with serial and VGA consoles.
|
||||||
|
|
||||||
|
coredump_filter=
|
||||||
|
[KNL] Change the default value for
|
||||||
|
/proc/<pid>/coredump_filter.
|
||||||
|
See also Documentation/filesystems/proc.txt.
|
||||||
|
|
||||||
cpcihp_generic= [HW,PCI] Generic port I/O CompactPCI driver
|
cpcihp_generic= [HW,PCI] Generic port I/O CompactPCI driver
|
||||||
Format:
|
Format:
|
||||||
<first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
|
<first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
|
||||||
|
@ -753,6 +765,14 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
parameter will force ia64_sal_cache_flush to call
|
parameter will force ia64_sal_cache_flush to call
|
||||||
ia64_pal_cache_flush instead of SAL_CACHE_FLUSH.
|
ia64_pal_cache_flush instead of SAL_CACHE_FLUSH.
|
||||||
|
|
||||||
|
ftrace=[tracer]
|
||||||
|
[ftrace] will set and start the specified tracer
|
||||||
|
as early as possible in order to facilitate early
|
||||||
|
boot debugging.
|
||||||
|
|
||||||
|
ftrace_dump_on_oops
|
||||||
|
[ftrace] will dump the trace buffers on oops.
|
||||||
|
|
||||||
gamecon.map[2|3]=
|
gamecon.map[2|3]=
|
||||||
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
|
[HW,JOY] Multisystem joystick and NES/SNES/PSX pad
|
||||||
support via parallel port (up to 5 devices per port)
|
support via parallel port (up to 5 devices per port)
|
||||||
|
@ -814,6 +834,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
|
|
||||||
hlt [BUGS=ARM,SH]
|
hlt [BUGS=ARM,SH]
|
||||||
|
|
||||||
|
hvc_iucv= [S390] Number of z/VM IUCV hypervisor console (HVC)
|
||||||
|
terminal devices. Valid values: 0..8
|
||||||
|
|
||||||
i8042.debug [HW] Toggle i8042 debug mode
|
i8042.debug [HW] Toggle i8042 debug mode
|
||||||
i8042.direct [HW] Put keyboard port into non-translated mode
|
i8042.direct [HW] Put keyboard port into non-translated mode
|
||||||
i8042.dumbkbd [HW] Pretend that controller can only read data from
|
i8042.dumbkbd [HW] Pretend that controller can only read data from
|
||||||
|
@ -860,17 +883,19 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
See Documentation/ide/ide.txt.
|
See Documentation/ide/ide.txt.
|
||||||
|
|
||||||
idle= [X86]
|
idle= [X86]
|
||||||
Format: idle=poll or idle=mwait, idle=halt, idle=nomwait
|
Format: idle=poll, idle=mwait, idle=halt, idle=nomwait
|
||||||
Poll forces a polling idle loop that can slightly improves the performance
|
Poll forces a polling idle loop that can slightly
|
||||||
of waking up a idle CPU, but will use a lot of power and make the system
|
improve the performance of waking up a idle CPU, but
|
||||||
run hot. Not recommended.
|
will use a lot of power and make the system run hot.
|
||||||
idle=mwait. On systems which support MONITOR/MWAIT but the kernel chose
|
Not recommended.
|
||||||
to not use it because it doesn't save as much power as a normal idle
|
idle=mwait: On systems which support MONITOR/MWAIT but
|
||||||
loop use the MONITOR/MWAIT idle loop anyways. Performance should be the same
|
the kernel chose to not use it because it doesn't save
|
||||||
as idle=poll.
|
as much power as a normal idle loop, use the
|
||||||
idle=halt. Halt is forced to be used for CPU idle.
|
MONITOR/MWAIT idle loop anyways. Performance should be
|
||||||
|
the same as idle=poll.
|
||||||
|
idle=halt: Halt is forced to be used for CPU idle.
|
||||||
In such case C2/C3 won't be used again.
|
In such case C2/C3 won't be used again.
|
||||||
idle=nomwait. Disable mwait for CPU C-states
|
idle=nomwait: Disable mwait for CPU C-states
|
||||||
|
|
||||||
ide-pci-generic.all-generic-ide [HW] (E)IDE subsystem
|
ide-pci-generic.all-generic-ide [HW] (E)IDE subsystem
|
||||||
Claim all unknown PCI IDE storage controllers.
|
Claim all unknown PCI IDE storage controllers.
|
||||||
|
@ -901,6 +926,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
|
|
||||||
inttest= [IA64]
|
inttest= [IA64]
|
||||||
|
|
||||||
|
iomem= Disable strict checking of access to MMIO memory
|
||||||
|
strict regions from userspace.
|
||||||
|
relaxed
|
||||||
|
|
||||||
iommu= [x86]
|
iommu= [x86]
|
||||||
off
|
off
|
||||||
force
|
force
|
||||||
|
@ -1052,8 +1081,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
lapic [X86-32,APIC] Enable the local APIC even if BIOS
|
lapic [X86-32,APIC] Enable the local APIC even if BIOS
|
||||||
disabled it.
|
disabled it.
|
||||||
|
|
||||||
lapic_timer_c2_ok [X86-32,x86-64,APIC] trust the local apic timer in
|
lapic_timer_c2_ok [X86-32,x86-64,APIC] trust the local apic timer
|
||||||
C2 power state.
|
in C2 power state.
|
||||||
|
|
||||||
libata.dma= [LIBATA] DMA control
|
libata.dma= [LIBATA] DMA control
|
||||||
libata.dma=0 Disable all PATA and SATA DMA
|
libata.dma=0 Disable all PATA and SATA DMA
|
||||||
|
@ -1105,6 +1134,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
If there are multiple matching configurations changing
|
If there are multiple matching configurations changing
|
||||||
the same attribute, the last one is used.
|
the same attribute, the last one is used.
|
||||||
|
|
||||||
|
lmb=debug [KNL] Enable lmb debug messages.
|
||||||
|
|
||||||
load_ramdisk= [RAM] List of ramdisks to load from floppy
|
load_ramdisk= [RAM] List of ramdisks to load from floppy
|
||||||
See Documentation/blockdev/ramdisk.txt.
|
See Documentation/blockdev/ramdisk.txt.
|
||||||
|
|
||||||
|
@ -1396,7 +1427,20 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
when a NMI is triggered.
|
when a NMI is triggered.
|
||||||
Format: [state][,regs][,debounce][,die]
|
Format: [state][,regs][,debounce][,die]
|
||||||
|
|
||||||
nmi_watchdog= [KNL,BUGS=X86-32] Debugging features for SMP kernels
|
nmi_watchdog= [KNL,BUGS=X86-32,X86-64] Debugging features for SMP kernels
|
||||||
|
Format: [panic,][num]
|
||||||
|
Valid num: 0,1,2
|
||||||
|
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
|
||||||
|
|
||||||
no387 [BUGS=X86-32] Tells the kernel to use the 387 maths
|
no387 [BUGS=X86-32] Tells the kernel to use the 387 maths
|
||||||
emulation library even if a 387 maths coprocessor
|
emulation library even if a 387 maths coprocessor
|
||||||
|
@ -1452,6 +1496,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
instruction doesn't work correctly and not to
|
instruction doesn't work correctly and not to
|
||||||
use it.
|
use it.
|
||||||
|
|
||||||
|
no_file_caps Tells the kernel not to honor file capabilities. The
|
||||||
|
only way then for a file to be executed with privilege
|
||||||
|
is to be setuid root or executed by root.
|
||||||
|
|
||||||
nohalt [IA-64] Tells the kernel not to use the power saving
|
nohalt [IA-64] Tells the kernel not to use the power saving
|
||||||
function PAL_HALT_LIGHT when idle. This increases
|
function PAL_HALT_LIGHT when idle. This increases
|
||||||
power-consumption. On the positive side, it reduces
|
power-consumption. On the positive side, it reduces
|
||||||
|
@ -1521,6 +1569,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
|
|
||||||
nosoftlockup [KNL] Disable the soft-lockup detector.
|
nosoftlockup [KNL] Disable the soft-lockup detector.
|
||||||
|
|
||||||
|
noswapaccount [KNL] Disable accounting of swap in memory resource
|
||||||
|
controller. (See Documentation/controllers/memory.txt)
|
||||||
|
|
||||||
nosync [HW,M68K] Disables sync negotiation for all devices.
|
nosync [HW,M68K] Disables sync negotiation for all devices.
|
||||||
|
|
||||||
notsc [BUGS=X86-32] Disable Time Stamp Counter
|
notsc [BUGS=X86-32] Disable Time Stamp Counter
|
||||||
|
@ -1540,6 +1591,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
|
|
||||||
nr_uarts= [SERIAL] maximum number of UARTs to be registered.
|
nr_uarts= [SERIAL] maximum number of UARTs to be registered.
|
||||||
|
|
||||||
|
ohci1394_dma=early [HW] enable debugging via the ohci1394 driver.
|
||||||
|
See Documentation/debugging-via-ohci1394.txt for more
|
||||||
|
info.
|
||||||
|
|
||||||
olpc_ec_timeout= [OLPC] ms delay when issuing EC commands
|
olpc_ec_timeout= [OLPC] ms delay when issuing EC commands
|
||||||
Rather than timing out after 20 ms if an EC
|
Rather than timing out after 20 ms if an EC
|
||||||
command is not properly ACKed, override the length
|
command is not properly ACKed, override the length
|
||||||
|
@ -1629,6 +1684,17 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
nomsi [MSI] If the PCI_MSI kernel config parameter is
|
nomsi [MSI] If the PCI_MSI kernel config parameter is
|
||||||
enabled, this kernel boot option can be used to
|
enabled, this kernel boot option can be used to
|
||||||
disable the use of MSI interrupts system-wide.
|
disable the use of MSI interrupts system-wide.
|
||||||
|
noioapicquirk [APIC] Disable all boot interrupt quirks.
|
||||||
|
Safety option to keep boot IRQs enabled. This
|
||||||
|
should never be necessary.
|
||||||
|
ioapicreroute [APIC] Enable rerouting of boot IRQs to the
|
||||||
|
primary IO-APIC for bridges that cannot disable
|
||||||
|
boot IRQs. This fixes a source of spurious IRQs
|
||||||
|
when the system masks IRQs.
|
||||||
|
noioapicreroute [APIC] Disable workaround that uses the
|
||||||
|
boot IRQ equivalent of an IRQ that connects to
|
||||||
|
a chipset where boot IRQs cannot be disabled.
|
||||||
|
The opposite of ioapicreroute.
|
||||||
biosirq [X86-32] Use PCI BIOS calls to get the interrupt
|
biosirq [X86-32] Use PCI BIOS calls to get the interrupt
|
||||||
routing table. These calls are known to be buggy
|
routing table. These calls are known to be buggy
|
||||||
on several machines and they hang the machine
|
on several machines and they hang the machine
|
||||||
|
@ -1753,10 +1819,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
autoconfiguration.
|
autoconfiguration.
|
||||||
Ranges are in pairs (memory base and size).
|
Ranges are in pairs (memory base and size).
|
||||||
|
|
||||||
dynamic_printk
|
dynamic_printk Enables pr_debug()/dev_dbg() calls if
|
||||||
Enables pr_debug()/dev_dbg() calls if
|
CONFIG_DYNAMIC_PRINTK_DEBUG has been enabled.
|
||||||
CONFIG_DYNAMIC_PRINTK_DEBUG has been enabled. These can also
|
These can also be switched on/off via
|
||||||
be switched on/off via <debugfs>/dynamic_printk/modules
|
<debugfs>/dynamic_printk/modules
|
||||||
|
|
||||||
print-fatal-signals=
|
print-fatal-signals=
|
||||||
[KNL] debug: print fatal signals
|
[KNL] debug: print fatal signals
|
||||||
|
@ -2168,6 +2234,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
st= [HW,SCSI] SCSI tape parameters (buffers, etc.)
|
st= [HW,SCSI] SCSI tape parameters (buffers, etc.)
|
||||||
See Documentation/scsi/st.txt.
|
See Documentation/scsi/st.txt.
|
||||||
|
|
||||||
|
stacktrace [FTRACE]
|
||||||
|
Enabled the stack tracer on boot up.
|
||||||
|
|
||||||
sti= [PARISC,HW]
|
sti= [PARISC,HW]
|
||||||
Format: <num>
|
Format: <num>
|
||||||
Set the STI (builtin display/keyboard on the HP-PARISC
|
Set the STI (builtin display/keyboard on the HP-PARISC
|
||||||
|
@ -2241,7 +2310,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
|
|
||||||
thermal.psv= [HW,ACPI]
|
thermal.psv= [HW,ACPI]
|
||||||
-1: disable all passive trip points
|
-1: disable all passive trip points
|
||||||
<degrees C>: override all passive trip points to this value
|
<degrees C>: override all passive trip points to this
|
||||||
|
value
|
||||||
|
|
||||||
thermal.tzp= [HW,ACPI]
|
thermal.tzp= [HW,ACPI]
|
||||||
Specify global default ACPI thermal zone polling rate
|
Specify global default ACPI thermal zone polling rate
|
||||||
|
@ -2252,12 +2322,27 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
See comment before function dc390_setup() in
|
See comment before function dc390_setup() in
|
||||||
drivers/scsi/tmscsim.c.
|
drivers/scsi/tmscsim.c.
|
||||||
|
|
||||||
|
topology= [S390]
|
||||||
|
Format: {off | on}
|
||||||
|
Specify if the kernel should make use of the cpu
|
||||||
|
topology informations if the hardware supports these.
|
||||||
|
The scheduler will make use of these informations and
|
||||||
|
e.g. base its process migration decisions on it.
|
||||||
|
Default is off.
|
||||||
|
|
||||||
tp720= [HW,PS2]
|
tp720= [HW,PS2]
|
||||||
|
|
||||||
trix= [HW,OSS] MediaTrix AudioTrix Pro
|
trix= [HW,OSS] MediaTrix AudioTrix Pro
|
||||||
Format:
|
Format:
|
||||||
<io>,<irq>,<dma>,<dma2>,<sb_io>,<sb_irq>,<sb_dma>,<mpu_io>,<mpu_irq>
|
<io>,<irq>,<dma>,<dma2>,<sb_io>,<sb_irq>,<sb_dma>,<mpu_io>,<mpu_irq>
|
||||||
|
|
||||||
|
tsc= Disable clocksource-must-verify flag 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.
|
||||||
|
|
||||||
turbografx.map[2|3]= [HW,JOY]
|
turbografx.map[2|3]= [HW,JOY]
|
||||||
TurboGraFX parallel port interface
|
TurboGraFX parallel port interface
|
||||||
Format:
|
Format:
|
||||||
|
@ -2314,6 +2399,41 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
usbhid.mousepoll=
|
usbhid.mousepoll=
|
||||||
[USBHID] The interval which mice are to be polled at.
|
[USBHID] The interval which mice are to be polled at.
|
||||||
|
|
||||||
|
usb-storage.delay_use=
|
||||||
|
[UMS] The delay in seconds before a new device is
|
||||||
|
scanned for Logical Units (default 5).
|
||||||
|
|
||||||
|
usb-storage.quirks=
|
||||||
|
[UMS] A list of quirks entries to supplement or
|
||||||
|
override the built-in unusual_devs list. List
|
||||||
|
entries are separated by commas. Each entry has
|
||||||
|
the form VID:PID:Flags where VID and PID are Vendor
|
||||||
|
and Product ID values (4-digit hex numbers) and
|
||||||
|
Flags is a set of characters, each corresponding
|
||||||
|
to a common usb-storage quirk flag as follows:
|
||||||
|
a = SANE_SENSE (collect more than 18 bytes
|
||||||
|
of sense data);
|
||||||
|
c = FIX_CAPACITY (decrease the reported
|
||||||
|
device capacity by one sector);
|
||||||
|
h = CAPACITY_HEURISTICS (decrease the
|
||||||
|
reported device capacity by one
|
||||||
|
sector if the number is odd);
|
||||||
|
i = IGNORE_DEVICE (don't bind to this
|
||||||
|
device);
|
||||||
|
l = NOT_LOCKABLE (don't try to lock and
|
||||||
|
unlock ejectable media);
|
||||||
|
m = MAX_SECTORS_64 (don't transfer more
|
||||||
|
than 64 sectors = 32 KB at a time);
|
||||||
|
o = CAPACITY_OK (accept the capacity
|
||||||
|
reported by the device);
|
||||||
|
r = IGNORE_RESIDUE (the device reports
|
||||||
|
bogus residue values);
|
||||||
|
s = SINGLE_LUN (the device has only one
|
||||||
|
Logical Unit);
|
||||||
|
w = NO_WP_DETECT (don't test whether the
|
||||||
|
medium is write-protected).
|
||||||
|
Example: quirks=0419:aaf5:rl,0421:0433:rc
|
||||||
|
|
||||||
add_efi_memmap [EFI; x86-32,X86-64] Include EFI memory map in
|
add_efi_memmap [EFI; x86-32,X86-64] Include EFI memory map in
|
||||||
kernel's map of available physical RAM.
|
kernel's map of available physical RAM.
|
||||||
|
|
||||||
|
@ -2374,8 +2494,8 @@ and is between 256 and 4096 characters. It is defined in the file
|
||||||
Format:
|
Format:
|
||||||
<irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]
|
<irq>,<irq_mask>,<io>,<full_duplex>,<do_sound>,<lockup_hack>[,<irq2>[,<irq3>[,<irq4>]]]
|
||||||
|
|
||||||
norandmaps Don't use address space randomization
|
norandmaps Don't use address space randomization. Equivalent to
|
||||||
Equivalent to echo 0 > /proc/sys/kernel/randomize_va_space
|
echo 0 > /proc/sys/kernel/randomize_va_space
|
||||||
|
|
||||||
______________________________________________________________________
|
______________________________________________________________________
|
||||||
|
|
||||||
|
|
|
@ -118,8 +118,8 @@ the name of the kobject, call kobject_rename():
|
||||||
|
|
||||||
int kobject_rename(struct kobject *kobj, const char *new_name);
|
int kobject_rename(struct kobject *kobj, const char *new_name);
|
||||||
|
|
||||||
Note kobject_rename does perform any locking or have a solid notion of
|
kobject_rename does not perform any locking or have a solid notion of
|
||||||
what names are valid so the provide must provide their own sanity checking
|
what names are valid so the caller must provide their own sanity checking
|
||||||
and serialization.
|
and serialization.
|
||||||
|
|
||||||
There is a function called kobject_set_name() but that is legacy cruft and
|
There is a function called kobject_set_name() but that is legacy cruft and
|
||||||
|
|
|
@ -497,7 +497,10 @@ The first column provides the kernel address where the probe is inserted.
|
||||||
The second column identifies the type of probe (k - kprobe, r - kretprobe
|
The second column identifies the type of probe (k - kprobe, r - kretprobe
|
||||||
and j - jprobe), while the third column specifies the symbol+offset of
|
and j - jprobe), while the third column specifies the symbol+offset of
|
||||||
the probe. If the probed function belongs to a module, the module name
|
the probe. If the probed function belongs to a module, the module name
|
||||||
is also specified.
|
is also specified. Following columns show probe status. If the probe is on
|
||||||
|
a virtual address that is no longer valid (module init sections, module
|
||||||
|
virtual addresses that correspond to modules that've been unloaded),
|
||||||
|
such probes are marked with [GONE].
|
||||||
|
|
||||||
/debug/kprobes/enabled: Turn kprobes ON/OFF
|
/debug/kprobes/enabled: Turn kprobes ON/OFF
|
||||||
|
|
||||||
|
|
|
@ -1475,7 +1475,7 @@ Sysfs interface changelog:
|
||||||
|
|
||||||
0x020100: Marker for thinkpad-acpi with hot key NVRAM polling
|
0x020100: Marker for thinkpad-acpi with hot key NVRAM polling
|
||||||
support. If you must, use it to know you should not
|
support. If you must, use it to know you should not
|
||||||
start an userspace NVRAM poller (allows to detect when
|
start a userspace NVRAM poller (allows to detect when
|
||||||
NVRAM is compiled out by the user because it is
|
NVRAM is compiled out by the user because it is
|
||||||
unneeded/undesired in the first place).
|
unneeded/undesired in the first place).
|
||||||
0x020101: Marker for thinkpad-acpi with hot key NVRAM polling
|
0x020101: Marker for thinkpad-acpi with hot key NVRAM polling
|
||||||
|
|
|
@ -481,51 +481,6 @@ static unsigned long load_initrd(const char *name, unsigned long mem)
|
||||||
/* We return the initrd size. */
|
/* We return the initrd size. */
|
||||||
return len;
|
return len;
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Once we know how much memory we have we can construct simple linear page
|
|
||||||
* tables which set virtual == physical which will get the Guest far enough
|
|
||||||
* into the boot to create its own.
|
|
||||||
*
|
|
||||||
* We lay them out of the way, just below the initrd (which is why we need to
|
|
||||||
* know its size here). */
|
|
||||||
static unsigned long setup_pagetables(unsigned long mem,
|
|
||||||
unsigned long initrd_size)
|
|
||||||
{
|
|
||||||
unsigned long *pgdir, *linear;
|
|
||||||
unsigned int mapped_pages, i, linear_pages;
|
|
||||||
unsigned int ptes_per_page = getpagesize()/sizeof(void *);
|
|
||||||
|
|
||||||
mapped_pages = mem/getpagesize();
|
|
||||||
|
|
||||||
/* Each PTE page can map ptes_per_page pages: how many do we need? */
|
|
||||||
linear_pages = (mapped_pages + ptes_per_page-1)/ptes_per_page;
|
|
||||||
|
|
||||||
/* We put the toplevel page directory page at the top of memory. */
|
|
||||||
pgdir = from_guest_phys(mem) - initrd_size - getpagesize();
|
|
||||||
|
|
||||||
/* Now we use the next linear_pages pages as pte pages */
|
|
||||||
linear = (void *)pgdir - linear_pages*getpagesize();
|
|
||||||
|
|
||||||
/* Linear mapping is easy: put every page's address into the mapping in
|
|
||||||
* order. PAGE_PRESENT contains the flags Present, Writable and
|
|
||||||
* Executable. */
|
|
||||||
for (i = 0; i < mapped_pages; i++)
|
|
||||||
linear[i] = ((i * getpagesize()) | PAGE_PRESENT);
|
|
||||||
|
|
||||||
/* The top level points to the linear page table pages above. */
|
|
||||||
for (i = 0; i < mapped_pages; i += ptes_per_page) {
|
|
||||||
pgdir[i/ptes_per_page]
|
|
||||||
= ((to_guest_phys(linear) + i*sizeof(void *))
|
|
||||||
| PAGE_PRESENT);
|
|
||||||
}
|
|
||||||
|
|
||||||
verbose("Linear mapping of %u pages in %u pte pages at %#lx\n",
|
|
||||||
mapped_pages, linear_pages, to_guest_phys(linear));
|
|
||||||
|
|
||||||
/* We return the top level (guest-physical) address: the kernel needs
|
|
||||||
* to know where it is. */
|
|
||||||
return to_guest_phys(pgdir);
|
|
||||||
}
|
|
||||||
/*:*/
|
/*:*/
|
||||||
|
|
||||||
/* Simple routine to roll all the commandline arguments together with spaces
|
/* Simple routine to roll all the commandline arguments together with spaces
|
||||||
|
@ -548,13 +503,13 @@ static void concat(char *dst, char *args[])
|
||||||
|
|
||||||
/*L:185 This is where we actually tell the kernel to initialize the Guest. We
|
/*L:185 This is where we actually tell the kernel to initialize the Guest. We
|
||||||
* saw the arguments it expects when we looked at initialize() in lguest_user.c:
|
* saw the arguments it expects when we looked at initialize() in lguest_user.c:
|
||||||
* the base of Guest "physical" memory, the top physical page to allow, the
|
* the base of Guest "physical" memory, the top physical page to allow and the
|
||||||
* top level pagetable and the entry point for the Guest. */
|
* entry point for the Guest. */
|
||||||
static int tell_kernel(unsigned long pgdir, unsigned long start)
|
static int tell_kernel(unsigned long start)
|
||||||
{
|
{
|
||||||
unsigned long args[] = { LHREQ_INITIALIZE,
|
unsigned long args[] = { LHREQ_INITIALIZE,
|
||||||
(unsigned long)guest_base,
|
(unsigned long)guest_base,
|
||||||
guest_limit / getpagesize(), pgdir, start };
|
guest_limit / getpagesize(), start };
|
||||||
int fd;
|
int fd;
|
||||||
|
|
||||||
verbose("Guest: %p - %p (%#lx)\n",
|
verbose("Guest: %p - %p (%#lx)\n",
|
||||||
|
@ -1030,7 +985,7 @@ static void update_device_status(struct device *dev)
|
||||||
/* Zero out the virtqueues. */
|
/* Zero out the virtqueues. */
|
||||||
for (vq = dev->vq; vq; vq = vq->next) {
|
for (vq = dev->vq; vq; vq = vq->next) {
|
||||||
memset(vq->vring.desc, 0,
|
memset(vq->vring.desc, 0,
|
||||||
vring_size(vq->config.num, getpagesize()));
|
vring_size(vq->config.num, LGUEST_VRING_ALIGN));
|
||||||
lg_last_avail(vq) = 0;
|
lg_last_avail(vq) = 0;
|
||||||
}
|
}
|
||||||
} else if (dev->desc->status & VIRTIO_CONFIG_S_FAILED) {
|
} else if (dev->desc->status & VIRTIO_CONFIG_S_FAILED) {
|
||||||
|
@ -1211,7 +1166,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
|
||||||
void *p;
|
void *p;
|
||||||
|
|
||||||
/* First we need some memory for this virtqueue. */
|
/* First we need some memory for this virtqueue. */
|
||||||
pages = (vring_size(num_descs, getpagesize()) + getpagesize() - 1)
|
pages = (vring_size(num_descs, LGUEST_VRING_ALIGN) + getpagesize() - 1)
|
||||||
/ getpagesize();
|
/ getpagesize();
|
||||||
p = get_pages(pages);
|
p = get_pages(pages);
|
||||||
|
|
||||||
|
@ -1228,7 +1183,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs,
|
||||||
vq->config.pfn = to_guest_phys(p) / getpagesize();
|
vq->config.pfn = to_guest_phys(p) / getpagesize();
|
||||||
|
|
||||||
/* Initialize the vring. */
|
/* Initialize the vring. */
|
||||||
vring_init(&vq->vring, num_descs, p, getpagesize());
|
vring_init(&vq->vring, num_descs, p, LGUEST_VRING_ALIGN);
|
||||||
|
|
||||||
/* Append virtqueue to this device's descriptor. We use
|
/* Append virtqueue to this device's descriptor. We use
|
||||||
* device_config() to get the end of the device's current virtqueues;
|
* device_config() to get the end of the device's current virtqueues;
|
||||||
|
@ -1941,7 +1896,7 @@ int main(int argc, char *argv[])
|
||||||
{
|
{
|
||||||
/* Memory, top-level pagetable, code startpoint and size of the
|
/* Memory, top-level pagetable, code startpoint and size of the
|
||||||
* (optional) initrd. */
|
* (optional) initrd. */
|
||||||
unsigned long mem = 0, pgdir, start, initrd_size = 0;
|
unsigned long mem = 0, start, initrd_size = 0;
|
||||||
/* Two temporaries and the /dev/lguest file descriptor. */
|
/* Two temporaries and the /dev/lguest file descriptor. */
|
||||||
int i, c, lguest_fd;
|
int i, c, lguest_fd;
|
||||||
/* The boot information for the Guest. */
|
/* The boot information for the Guest. */
|
||||||
|
@ -2040,9 +1995,6 @@ int main(int argc, char *argv[])
|
||||||
boot->hdr.type_of_loader = 0xFF;
|
boot->hdr.type_of_loader = 0xFF;
|
||||||
}
|
}
|
||||||
|
|
||||||
/* Set up the initial linear pagetables, starting below the initrd. */
|
|
||||||
pgdir = setup_pagetables(mem, initrd_size);
|
|
||||||
|
|
||||||
/* The Linux boot header contains an "E820" memory map: ours is a
|
/* The Linux boot header contains an "E820" memory map: ours is a
|
||||||
* simple, single region. */
|
* simple, single region. */
|
||||||
boot->e820_entries = 1;
|
boot->e820_entries = 1;
|
||||||
|
@ -2064,7 +2016,7 @@ int main(int argc, char *argv[])
|
||||||
|
|
||||||
/* We tell the kernel to initialize the Guest: this returns the open
|
/* We tell the kernel to initialize the Guest: this returns the open
|
||||||
* /dev/lguest file descriptor. */
|
* /dev/lguest file descriptor. */
|
||||||
lguest_fd = tell_kernel(pgdir, start);
|
lguest_fd = tell_kernel(start);
|
||||||
|
|
||||||
/* We clone off a thread, which wakes the Launcher whenever one of the
|
/* We clone off a thread, which wakes the Launcher whenever one of the
|
||||||
* input file descriptors needs attention. We call this the Waker, and
|
* input file descriptors needs attention. We call this the Waker, and
|
||||||
|
|
|
@ -71,35 +71,50 @@ Look at the current lock statistics:
|
||||||
|
|
||||||
# less /proc/lock_stat
|
# less /proc/lock_stat
|
||||||
|
|
||||||
01 lock_stat version 0.2
|
01 lock_stat version 0.3
|
||||||
02 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
02 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
03 class name con-bounces contentions waittime-min waittime-max waittime-total acq-bounces acquisitions holdtime-min holdtime-max holdtime-total
|
03 class name con-bounces contentions waittime-min waittime-max waittime-total acq-bounces acquisitions holdtime-min holdtime-max holdtime-total
|
||||||
04 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
04 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
||||||
05
|
05
|
||||||
06 &inode->i_data.tree_lock-W: 15 21657 0.18 1093295.30 11547131054.85 58 10415 0.16 87.51 6387.60
|
06 &mm->mmap_sem-W: 233 538 18446744073708 22924.27 607243.51 1342 45806 1.71 8595.89 1180582.34
|
||||||
07 &inode->i_data.tree_lock-R: 0 0 0.00 0.00 0.00 23302 231198 0.25 8.45 98023.38
|
07 &mm->mmap_sem-R: 205 587 18446744073708 28403.36 731975.00 1940 412426 0.58 187825.45 6307502.88
|
||||||
08 --------------------------
|
08 ---------------
|
||||||
09 &inode->i_data.tree_lock 0 [<ffffffff8027c08f>] add_to_page_cache+0x5f/0x190
|
09 &mm->mmap_sem 487 [<ffffffff8053491f>] do_page_fault+0x466/0x928
|
||||||
10
|
10 &mm->mmap_sem 179 [<ffffffff802a6200>] sys_mprotect+0xcd/0x21d
|
||||||
11 ...............................................................................................................................................................................................
|
11 &mm->mmap_sem 279 [<ffffffff80210a57>] sys_mmap+0x75/0xce
|
||||||
12
|
12 &mm->mmap_sem 76 [<ffffffff802a490b>] sys_munmap+0x32/0x59
|
||||||
13 dcache_lock: 1037 1161 0.38 45.32 774.51 6611 243371 0.15 306.48 77387.24
|
13 ---------------
|
||||||
14 -----------
|
14 &mm->mmap_sem 270 [<ffffffff80210a57>] sys_mmap+0x75/0xce
|
||||||
15 dcache_lock 180 [<ffffffff802c0d7e>] sys_getcwd+0x11e/0x230
|
15 &mm->mmap_sem 431 [<ffffffff8053491f>] do_page_fault+0x466/0x928
|
||||||
16 dcache_lock 165 [<ffffffff802c002a>] d_alloc+0x15a/0x210
|
16 &mm->mmap_sem 138 [<ffffffff802a490b>] sys_munmap+0x32/0x59
|
||||||
17 dcache_lock 33 [<ffffffff8035818d>] _atomic_dec_and_lock+0x4d/0x70
|
17 &mm->mmap_sem 145 [<ffffffff802a6200>] sys_mprotect+0xcd/0x21d
|
||||||
18 dcache_lock 1 [<ffffffff802beef8>] shrink_dcache_parent+0x18/0x130
|
18
|
||||||
|
19 ...............................................................................................................................................................................................
|
||||||
|
20
|
||||||
|
21 dcache_lock: 621 623 0.52 118.26 1053.02 6745 91930 0.29 316.29 118423.41
|
||||||
|
22 -----------
|
||||||
|
23 dcache_lock 179 [<ffffffff80378274>] _atomic_dec_and_lock+0x34/0x54
|
||||||
|
24 dcache_lock 113 [<ffffffff802cc17b>] d_alloc+0x19a/0x1eb
|
||||||
|
25 dcache_lock 99 [<ffffffff802ca0dc>] d_rehash+0x1b/0x44
|
||||||
|
26 dcache_lock 104 [<ffffffff802cbca0>] d_instantiate+0x36/0x8a
|
||||||
|
27 -----------
|
||||||
|
28 dcache_lock 192 [<ffffffff80378274>] _atomic_dec_and_lock+0x34/0x54
|
||||||
|
29 dcache_lock 98 [<ffffffff802ca0dc>] d_rehash+0x1b/0x44
|
||||||
|
30 dcache_lock 72 [<ffffffff802cc17b>] d_alloc+0x19a/0x1eb
|
||||||
|
31 dcache_lock 112 [<ffffffff802cbca0>] d_instantiate+0x36/0x8a
|
||||||
|
|
||||||
This excerpt shows the first two lock class statistics. Line 01 shows the
|
This excerpt shows the first two lock class statistics. Line 01 shows the
|
||||||
output version - each time the format changes this will be updated. Line 02-04
|
output version - each time the format changes this will be updated. Line 02-04
|
||||||
show the header with column descriptions. Lines 05-10 and 13-18 show the actual
|
show the header with column descriptions. Lines 05-18 and 20-31 show the actual
|
||||||
statistics. These statistics come in two parts; the actual stats separated by a
|
statistics. These statistics come in two parts; the actual stats separated by a
|
||||||
short separator (line 08, 14) from the contention points.
|
short separator (line 08, 13) from the contention points.
|
||||||
|
|
||||||
The first lock (05-10) is a read/write lock, and shows two lines above the
|
The first lock (05-18) is a read/write lock, and shows two lines above the
|
||||||
short separator. The contention points don't match the column descriptors,
|
short separator. The contention points don't match the column descriptors,
|
||||||
they have two: contentions and [<IP>] symbol.
|
they have two: contentions and [<IP>] symbol. The second set of contention
|
||||||
|
points are the points we're contending with.
|
||||||
|
|
||||||
|
The integer part of the time values is in us.
|
||||||
|
|
||||||
View the top contending locks:
|
View the top contending locks:
|
||||||
|
|
||||||
|
|
|
@ -125,14 +125,14 @@ TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c
|
||||||
ROUTER_MAGIC 0x524d4157 wan_device include/linux/wanrouter.h
|
ROUTER_MAGIC 0x524d4157 wan_device include/linux/wanrouter.h
|
||||||
SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h
|
SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h
|
||||||
SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c
|
SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c
|
||||||
GDA_MAGIC 0x58464552 gda include/asm-mips64/sn/gda.h
|
GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h
|
||||||
RED_MAGIC1 0x5a2cf071 (any) mm/slab.c
|
RED_MAGIC1 0x5a2cf071 (any) mm/slab.c
|
||||||
STL_PORTMAGIC 0x5a7182c9 stlport include/linux/stallion.h
|
STL_PORTMAGIC 0x5a7182c9 stlport include/linux/stallion.h
|
||||||
EEPROM_MAGIC_VALUE 0x5ab478d2 lanai_dev drivers/atm/lanai.c
|
EEPROM_MAGIC_VALUE 0x5ab478d2 lanai_dev drivers/atm/lanai.c
|
||||||
HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state include/linux/hdlcdrv.h
|
HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state include/linux/hdlcdrv.h
|
||||||
EPCA_MAGIC 0x5c6df104 channel include/linux/epca.h
|
EPCA_MAGIC 0x5c6df104 channel include/linux/epca.h
|
||||||
PCXX_MAGIC 0x5c6df104 channel drivers/char/pcxx.h
|
PCXX_MAGIC 0x5c6df104 channel drivers/char/pcxx.h
|
||||||
KV_MAGIC 0x5f4b565f kernel_vars_s include/asm-mips64/sn/klkernvars.h
|
KV_MAGIC 0x5f4b565f kernel_vars_s arch/mips/include/asm/sn/klkernvars.h
|
||||||
I810_STATE_MAGIC 0x63657373 i810_state sound/oss/i810_audio.c
|
I810_STATE_MAGIC 0x63657373 i810_state sound/oss/i810_audio.c
|
||||||
TRIDENT_STATE_MAGIC 0x63657373 trient_state sound/oss/trident.c
|
TRIDENT_STATE_MAGIC 0x63657373 trient_state sound/oss/trident.c
|
||||||
M3_CARD_MAGIC 0x646e6f50 m3_card sound/oss/maestro3.c
|
M3_CARD_MAGIC 0x646e6f50 m3_card sound/oss/maestro3.c
|
||||||
|
@ -158,7 +158,7 @@ CCB_MAGIC 0xf2691ad2 ccb drivers/scsi/ncr53c8xx.c
|
||||||
QUEUE_MAGIC_FREE 0xf7e1c9a3 queue_entry drivers/scsi/arm/queue.c
|
QUEUE_MAGIC_FREE 0xf7e1c9a3 queue_entry drivers/scsi/arm/queue.c
|
||||||
QUEUE_MAGIC_USED 0xf7e1cc33 queue_entry drivers/scsi/arm/queue.c
|
QUEUE_MAGIC_USED 0xf7e1cc33 queue_entry drivers/scsi/arm/queue.c
|
||||||
HTB_CMAGIC 0xFEFAFEF1 htb_class net/sched/sch_htb.c
|
HTB_CMAGIC 0xFEFAFEF1 htb_class net/sched/sch_htb.c
|
||||||
NMI_MAGIC 0x48414d4d455201 nmi_s include/asm-mips64/sn/nmi.h
|
NMI_MAGIC 0x48414d4d455201 nmi_s arch/mips/include/asm/sn/nmi.h
|
||||||
|
|
||||||
Note that there are also defined special per-driver magic numbers in sound
|
Note that there are also defined special per-driver magic numbers in sound
|
||||||
memory management. See include/sound/sndmagic.h for complete list of them. Many
|
memory management. See include/sound/sndmagic.h for complete list of them. Many
|
||||||
|
|
|
@ -51,11 +51,16 @@ to call) for the specific marker through marker_probe_register() and can be
|
||||||
activated by calling marker_arm(). Marker deactivation can be done by calling
|
activated by calling marker_arm(). Marker deactivation can be done by calling
|
||||||
marker_disarm() as many times as marker_arm() has been called. Removing a probe
|
marker_disarm() as many times as marker_arm() has been called. Removing a probe
|
||||||
is done through marker_probe_unregister(); it will disarm the probe.
|
is done through marker_probe_unregister(); it will disarm the probe.
|
||||||
marker_synchronize_unregister() must be called before the end of the module exit
|
|
||||||
function to make sure there is no caller left using the probe. This, and the
|
marker_synchronize_unregister() must be called between probe unregistration and
|
||||||
fact that preemption is disabled around the probe call, make sure that probe
|
the first occurrence of
|
||||||
removal and module unload are safe. See the "Probe example" section below for a
|
- the end of module exit function,
|
||||||
sample probe module.
|
to make sure there is no caller left using the probe;
|
||||||
|
- the free of any resource used by the probes,
|
||||||
|
to make sure the probes wont be accessing invalid data.
|
||||||
|
This, and the fact that preemption is disabled around the probe call, make sure
|
||||||
|
that probe removal and module unload are safe. See the "Probe example" section
|
||||||
|
below for a sample probe module.
|
||||||
|
|
||||||
The marker mechanism supports inserting multiple instances of the same marker.
|
The marker mechanism supports inserting multiple instances of the same marker.
|
||||||
Markers can be put in inline functions, inlined static functions, and
|
Markers can be put in inline functions, inlined static functions, and
|
||||||
|
@ -70,6 +75,20 @@ a printk warning which identifies the inconsistency:
|
||||||
|
|
||||||
"Format mismatch for probe probe_name (format), marker (format)"
|
"Format mismatch for probe probe_name (format), marker (format)"
|
||||||
|
|
||||||
|
Another way to use markers is to simply define the marker without generating any
|
||||||
|
function call to actually call into the marker. This is useful in combination
|
||||||
|
with tracepoint probes in a scheme like this :
|
||||||
|
|
||||||
|
void probe_tracepoint_name(unsigned int arg1, struct task_struct *tsk);
|
||||||
|
|
||||||
|
DEFINE_MARKER_TP(marker_eventname, tracepoint_name, probe_tracepoint_name,
|
||||||
|
"arg1 %u pid %d");
|
||||||
|
|
||||||
|
notrace void probe_tracepoint_name(unsigned int arg1, struct task_struct *tsk)
|
||||||
|
{
|
||||||
|
struct marker *marker = &GET_MARKER(kernel_irq_entry);
|
||||||
|
/* write data to trace buffers ... */
|
||||||
|
}
|
||||||
|
|
||||||
* Probe / marker example
|
* Probe / marker example
|
||||||
|
|
||||||
|
|
|
@ -124,7 +124,7 @@ config options.
|
||||||
This option can be kernel module too.
|
This option can be kernel module too.
|
||||||
|
|
||||||
--------------------------------
|
--------------------------------
|
||||||
3 sysfs files for memory hotplug
|
4 sysfs files for memory hotplug
|
||||||
--------------------------------
|
--------------------------------
|
||||||
All sections have their device information under /sys/devices/system/memory as
|
All sections have their device information under /sys/devices/system/memory as
|
||||||
|
|
||||||
|
@ -138,11 +138,12 @@ For example, assume 1GiB section size. A device for a memory starting at
|
||||||
(0x100000000 / 1Gib = 4)
|
(0x100000000 / 1Gib = 4)
|
||||||
This device covers address range [0x100000000 ... 0x140000000)
|
This device covers address range [0x100000000 ... 0x140000000)
|
||||||
|
|
||||||
Under each section, you can see 3 files.
|
Under each section, you can see 4 files.
|
||||||
|
|
||||||
/sys/devices/system/memory/memoryXXX/phys_index
|
/sys/devices/system/memory/memoryXXX/phys_index
|
||||||
/sys/devices/system/memory/memoryXXX/phys_device
|
/sys/devices/system/memory/memoryXXX/phys_device
|
||||||
/sys/devices/system/memory/memoryXXX/state
|
/sys/devices/system/memory/memoryXXX/state
|
||||||
|
/sys/devices/system/memory/memoryXXX/removable
|
||||||
|
|
||||||
'phys_index' : read-only and contains section id, same as XXX.
|
'phys_index' : read-only and contains section id, same as XXX.
|
||||||
'state' : read-write
|
'state' : read-write
|
||||||
|
@ -150,10 +151,20 @@ Under each section, you can see 3 files.
|
||||||
at write: user can specify "online", "offline" command
|
at write: user can specify "online", "offline" command
|
||||||
'phys_device': read-only: designed to show the name of physical memory device.
|
'phys_device': read-only: designed to show the name of physical memory device.
|
||||||
This is not well implemented now.
|
This is not well implemented now.
|
||||||
|
'removable' : read-only: contains an integer value indicating
|
||||||
|
whether the memory section is removable or not
|
||||||
|
removable. A value of 1 indicates that the memory
|
||||||
|
section is removable and a value of 0 indicates that
|
||||||
|
it is not removable.
|
||||||
|
|
||||||
NOTE:
|
NOTE:
|
||||||
These directories/files appear after physical memory hotplug phase.
|
These directories/files appear after physical memory hotplug phase.
|
||||||
|
|
||||||
|
If CONFIG_NUMA is enabled the
|
||||||
|
/sys/devices/system/memory/memoryXXX memory section
|
||||||
|
directories can also be accessed via symbolic links located in
|
||||||
|
the /sys/devices/system/node/node* directories. For example:
|
||||||
|
/sys/devices/system/node/node0/memory9 -> ../../memory/memory9
|
||||||
|
|
||||||
--------------------------------
|
--------------------------------
|
||||||
4. Physical memory hot-add phase
|
4. Physical memory hot-add phase
|
||||||
|
@ -365,7 +376,6 @@ node if necessary.
|
||||||
- allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like
|
- allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like
|
||||||
sysctl or new control file.
|
sysctl or new control file.
|
||||||
- showing memory section and physical device relationship.
|
- showing memory section and physical device relationship.
|
||||||
- showing memory section and node relationship (maybe good for NUMA)
|
|
||||||
- showing memory section is under ZONE_MOVABLE or not
|
- showing memory section is under ZONE_MOVABLE or not
|
||||||
- test and make it better memory offlining.
|
- test and make it better memory offlining.
|
||||||
- support HugeTLB page migration and offlining.
|
- support HugeTLB page migration and offlining.
|
||||||
|
|
|
@ -44,7 +44,7 @@ FILES, CONFIGS AND COMPATABILITY
|
||||||
|
|
||||||
Two files are introduced:
|
Two files are introduced:
|
||||||
|
|
||||||
a) 'include/asm-mips/mach-au1x00/au1xxx_ide.h'
|
a) 'arch/mips/include/asm/mach-au1x00/au1xxx_ide.h'
|
||||||
containes : struct _auide_hwif
|
containes : struct _auide_hwif
|
||||||
timing parameters for PIO mode 0/1/2/3/4
|
timing parameters for PIO mode 0/1/2/3/4
|
||||||
timing parameters for MWDMA 0/1/2
|
timing parameters for MWDMA 0/1/2
|
||||||
|
@ -52,14 +52,12 @@ Two files are introduced:
|
||||||
b) 'drivers/ide/mips/au1xxx-ide.c'
|
b) 'drivers/ide/mips/au1xxx-ide.c'
|
||||||
contains the functionality of the AU1XXX IDE driver
|
contains the functionality of the AU1XXX IDE driver
|
||||||
|
|
||||||
Four configs variables are introduced:
|
Following extra configs variables are introduced:
|
||||||
|
|
||||||
CONFIG_BLK_DEV_IDE_AU1XXX_PIO_DBDMA - enable the PIO+DBDMA mode
|
CONFIG_BLK_DEV_IDE_AU1XXX_PIO_DBDMA - enable the PIO+DBDMA mode
|
||||||
CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA - enable the MWDMA mode
|
CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA - enable the MWDMA mode
|
||||||
CONFIG_BLK_DEV_IDE_AU1XXX_BURSTABLE_ON - set Burstable FIFO in DBDMA
|
CONFIG_BLK_DEV_IDE_AU1XXX_BURSTABLE_ON - set Burstable FIFO in DBDMA
|
||||||
controller
|
controller
|
||||||
CONFIG_BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ - maximum transfer size
|
|
||||||
per descriptor
|
|
||||||
|
|
||||||
|
|
||||||
SUPPORTED IDE MODES
|
SUPPORTED IDE MODES
|
||||||
|
@ -87,7 +85,6 @@ CONFIG_BLK_DEV_IDEDMA_PCI=y
|
||||||
CONFIG_IDEDMA_PCI_AUTO=y
|
CONFIG_IDEDMA_PCI_AUTO=y
|
||||||
CONFIG_BLK_DEV_IDE_AU1XXX=y
|
CONFIG_BLK_DEV_IDE_AU1XXX=y
|
||||||
CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA=y
|
CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA=y
|
||||||
CONFIG_BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ=128
|
|
||||||
CONFIG_BLK_DEV_IDEDMA=y
|
CONFIG_BLK_DEV_IDEDMA=y
|
||||||
CONFIG_IDEDMA_AUTO=y
|
CONFIG_IDEDMA_AUTO=y
|
||||||
|
|
||||||
|
@ -105,7 +102,6 @@ CONFIG_BLK_DEV_IDEDMA_PCI=y
|
||||||
CONFIG_IDEDMA_PCI_AUTO=y
|
CONFIG_IDEDMA_PCI_AUTO=y
|
||||||
CONFIG_BLK_DEV_IDE_AU1XXX=y
|
CONFIG_BLK_DEV_IDE_AU1XXX=y
|
||||||
CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA=y
|
CONFIG_BLK_DEV_IDE_AU1XXX_MDMA2_DBDMA=y
|
||||||
CONFIG_BLK_DEV_IDE_AU1XXX_SEQTS_PER_RQ=128
|
|
||||||
CONFIG_BLK_DEV_IDEDMA=y
|
CONFIG_BLK_DEV_IDEDMA=y
|
||||||
CONFIG_IDEDMA_AUTO=y
|
CONFIG_IDEDMA_AUTO=y
|
||||||
|
|
||||||
|
|
|
@ -147,7 +147,7 @@ Where the supported parameter are:
|
||||||
driver. If disabled, the driver will not attempt to scan
|
driver. If disabled, the driver will not attempt to scan
|
||||||
for and associate to a network until it has been configured with
|
for and associate to a network until it has been configured with
|
||||||
one or more properties for the target network, for example configuring
|
one or more properties for the target network, for example configuring
|
||||||
the network SSID. Default is 1 (auto-associate)
|
the network SSID. Default is 0 (do not auto-associate)
|
||||||
|
|
||||||
Example: % modprobe ipw2200 associate=0
|
Example: % modprobe ipw2200 associate=0
|
||||||
|
|
||||||
|
|
|
@ -194,6 +194,48 @@ or, for backwards compatibility, the option value. E.g.,
|
||||||
|
|
||||||
The parameters are as follows:
|
The parameters are as follows:
|
||||||
|
|
||||||
|
ad_select
|
||||||
|
|
||||||
|
Specifies the 802.3ad aggregation selection logic to use. The
|
||||||
|
possible values and their effects are:
|
||||||
|
|
||||||
|
stable or 0
|
||||||
|
|
||||||
|
The active aggregator is chosen by largest aggregate
|
||||||
|
bandwidth.
|
||||||
|
|
||||||
|
Reselection of the active aggregator occurs only when all
|
||||||
|
slaves of the active aggregator are down or the active
|
||||||
|
aggregator has no slaves.
|
||||||
|
|
||||||
|
This is the default value.
|
||||||
|
|
||||||
|
bandwidth or 1
|
||||||
|
|
||||||
|
The active aggregator is chosen by largest aggregate
|
||||||
|
bandwidth. Reselection occurs if:
|
||||||
|
|
||||||
|
- A slave is added to or removed from the bond
|
||||||
|
|
||||||
|
- Any slave's link state changes
|
||||||
|
|
||||||
|
- Any slave's 802.3ad association state changes
|
||||||
|
|
||||||
|
- The bond's adminstrative state changes to up
|
||||||
|
|
||||||
|
count or 2
|
||||||
|
|
||||||
|
The active aggregator is chosen by the largest number of
|
||||||
|
ports (slaves). Reselection occurs as described under the
|
||||||
|
"bandwidth" setting, above.
|
||||||
|
|
||||||
|
The bandwidth and count selection policies permit failover of
|
||||||
|
802.3ad aggregations when partial failure of the active aggregator
|
||||||
|
occurs. This keeps the aggregator with the highest availability
|
||||||
|
(either in bandwidth or in number of ports) active at all times.
|
||||||
|
|
||||||
|
This option was added in bonding version 3.4.0.
|
||||||
|
|
||||||
arp_interval
|
arp_interval
|
||||||
|
|
||||||
Specifies the ARP link monitoring frequency in milliseconds.
|
Specifies the ARP link monitoring frequency in milliseconds.
|
||||||
|
@ -551,6 +593,16 @@ num_grat_arp
|
||||||
affects only the active-backup mode. This option was added for
|
affects only the active-backup mode. This option was added for
|
||||||
bonding version 3.3.0.
|
bonding version 3.3.0.
|
||||||
|
|
||||||
|
num_unsol_na
|
||||||
|
|
||||||
|
Specifies the number of unsolicited IPv6 Neighbor Advertisements
|
||||||
|
to be issued after a failover event. One unsolicited NA is issued
|
||||||
|
immediately after the failover.
|
||||||
|
|
||||||
|
The valid range is 0 - 255; the default value is 1. This option
|
||||||
|
affects only the active-backup mode. This option was added for
|
||||||
|
bonding version 3.4.0.
|
||||||
|
|
||||||
primary
|
primary
|
||||||
|
|
||||||
A string (eth0, eth2, etc) specifying which slave is the
|
A string (eth0, eth2, etc) specifying which slave is the
|
||||||
|
@ -922,17 +974,19 @@ USERCTL=no
|
||||||
NETMASK, NETWORK and BROADCAST) to match your network configuration.
|
NETMASK, NETWORK and BROADCAST) to match your network configuration.
|
||||||
|
|
||||||
For later versions of initscripts, such as that found with Fedora
|
For later versions of initscripts, such as that found with Fedora
|
||||||
7 and Red Hat Enterprise Linux version 5 (or later), it is possible, and,
|
7 (or later) and Red Hat Enterprise Linux version 5 (or later), it is possible,
|
||||||
indeed, preferable, to specify the bonding options in the ifcfg-bond0
|
and, indeed, preferable, to specify the bonding options in the ifcfg-bond0
|
||||||
file, e.g. a line of the format:
|
file, e.g. a line of the format:
|
||||||
|
|
||||||
BONDING_OPTS="mode=active-backup arp_interval=60 arp_ip_target=+192.168.1.254"
|
BONDING_OPTS="mode=active-backup arp_interval=60 arp_ip_target=192.168.1.254"
|
||||||
|
|
||||||
will configure the bond with the specified options. The options
|
will configure the bond with the specified options. The options
|
||||||
specified in BONDING_OPTS are identical to the bonding module parameters
|
specified in BONDING_OPTS are identical to the bonding module parameters
|
||||||
except for the arp_ip_target field. Each target should be included as a
|
except for the arp_ip_target field when using versions of initscripts older
|
||||||
separate option and should be preceded by a '+' to indicate it should be
|
than and 8.57 (Fedora 8) and 8.45.19 (Red Hat Enterprise Linux 5.2). When
|
||||||
added to the list of queried targets, e.g.,
|
using older versions each target should be included as a separate option and
|
||||||
|
should be preceded by a '+' to indicate it should be added to the list of
|
||||||
|
queried targets, e.g.,
|
||||||
|
|
||||||
arp_ip_target=+192.168.1.1 arp_ip_target=+192.168.1.2
|
arp_ip_target=+192.168.1.1 arp_ip_target=+192.168.1.2
|
||||||
|
|
||||||
|
@ -940,7 +994,7 @@ added to the list of queried targets, e.g.,
|
||||||
options via BONDING_OPTS, it is not necessary to edit /etc/modules.conf or
|
options via BONDING_OPTS, it is not necessary to edit /etc/modules.conf or
|
||||||
/etc/modprobe.conf.
|
/etc/modprobe.conf.
|
||||||
|
|
||||||
For older versions of initscripts that do not support
|
For even older versions of initscripts that do not support
|
||||||
BONDING_OPTS, it is necessary to edit /etc/modules.conf (or
|
BONDING_OPTS, it is necessary to edit /etc/modules.conf (or
|
||||||
/etc/modprobe.conf, depending upon your distro) to load the bonding module
|
/etc/modprobe.conf, depending upon your distro) to load the bonding module
|
||||||
with your desired options when the bond0 interface is brought up. The
|
with your desired options when the bond0 interface is brought up. The
|
||||||
|
|
|
@ -57,6 +57,24 @@ can be set before calling bind().
|
||||||
DCCP_SOCKOPT_GET_CUR_MPS is read-only and retrieves the current maximum packet
|
DCCP_SOCKOPT_GET_CUR_MPS is read-only and retrieves the current maximum packet
|
||||||
size (application payload size) in bytes, see RFC 4340, section 14.
|
size (application payload size) in bytes, see RFC 4340, section 14.
|
||||||
|
|
||||||
|
DCCP_SOCKOPT_AVAILABLE_CCIDS is also read-only and returns the list of CCIDs
|
||||||
|
supported by the endpoint (see include/linux/dccp.h for symbolic constants).
|
||||||
|
The caller needs to provide a sufficiently large (> 2) array of type uint8_t.
|
||||||
|
|
||||||
|
DCCP_SOCKOPT_CCID is write-only and sets both the TX and RX CCIDs at the same
|
||||||
|
time, combining the operation of the next two socket options. This option is
|
||||||
|
preferrable over the latter two, since often applications will use the same
|
||||||
|
type of CCID for both directions; and mixed use of CCIDs is not currently well
|
||||||
|
understood. This socket option takes as argument at least one uint8_t value, or
|
||||||
|
an array of uint8_t values, which must match available CCIDS (see above). CCIDs
|
||||||
|
must be registered on the socket before calling connect() or listen().
|
||||||
|
|
||||||
|
DCCP_SOCKOPT_TX_CCID is read/write. It returns the current CCID (if set) or sets
|
||||||
|
the preference list for the TX CCID, using the same format as DCCP_SOCKOPT_CCID.
|
||||||
|
Please note that the getsockopt argument type here is `int', not uint8_t.
|
||||||
|
|
||||||
|
DCCP_SOCKOPT_RX_CCID is analogous to DCCP_SOCKOPT_TX_CCID, but for the RX CCID.
|
||||||
|
|
||||||
DCCP_SOCKOPT_SERVER_TIMEWAIT enables the server (listening socket) to hold
|
DCCP_SOCKOPT_SERVER_TIMEWAIT enables the server (listening socket) to hold
|
||||||
timewait state when closing the connection (RFC 4340, 8.3). The usual case is
|
timewait state when closing the connection (RFC 4340, 8.3). The usual case is
|
||||||
that the closing server sends a CloseReq, whereupon the client holds timewait
|
that the closing server sends a CloseReq, whereupon the client holds timewait
|
||||||
|
@ -115,20 +133,12 @@ retries2
|
||||||
importance for retransmitted acknowledgments and feature negotiation,
|
importance for retransmitted acknowledgments and feature negotiation,
|
||||||
data packets are never retransmitted. Analogue of tcp_retries2.
|
data packets are never retransmitted. Analogue of tcp_retries2.
|
||||||
|
|
||||||
send_ndp = 1
|
|
||||||
Whether or not to send NDP count options (sec. 7.7.2).
|
|
||||||
|
|
||||||
send_ackvec = 1
|
|
||||||
Whether or not to send Ack Vector options (sec. 11.5).
|
|
||||||
|
|
||||||
ack_ratio = 2
|
|
||||||
The default Ack Ratio (sec. 11.3) to use.
|
|
||||||
|
|
||||||
tx_ccid = 2
|
tx_ccid = 2
|
||||||
Default CCID for the sender-receiver half-connection.
|
Default CCID for the sender-receiver half-connection. Depending on the
|
||||||
|
choice of CCID, the Send Ack Vector feature is enabled automatically.
|
||||||
|
|
||||||
rx_ccid = 2
|
rx_ccid = 2
|
||||||
Default CCID for the receiver-sender half-connection.
|
Default CCID for the receiver-sender half-connection; see tx_ccid.
|
||||||
|
|
||||||
seq_window = 100
|
seq_window = 100
|
||||||
The initial sequence window (sec. 7.5.2).
|
The initial sequence window (sec. 7.5.2).
|
||||||
|
|
|
@ -13,7 +13,7 @@ Transmit path guidelines:
|
||||||
static int drv_hard_start_xmit(struct sk_buff *skb,
|
static int drv_hard_start_xmit(struct sk_buff *skb,
|
||||||
struct net_device *dev)
|
struct net_device *dev)
|
||||||
{
|
{
|
||||||
struct drv *dp = dev->priv;
|
struct drv *dp = netdev_priv(dev);
|
||||||
|
|
||||||
lock_tx(dp);
|
lock_tx(dp);
|
||||||
...
|
...
|
||||||
|
|
|
@ -3,15 +3,15 @@ Krzysztof Halasa <khc@pm.waw.pl>
|
||||||
|
|
||||||
|
|
||||||
Generic HDLC layer currently supports:
|
Generic HDLC layer currently supports:
|
||||||
1. Frame Relay (ANSI, CCITT, Cisco and no LMI).
|
1. Frame Relay (ANSI, CCITT, Cisco and no LMI)
|
||||||
- Normal (routed) and Ethernet-bridged (Ethernet device emulation)
|
- Normal (routed) and Ethernet-bridged (Ethernet device emulation)
|
||||||
interfaces can share a single PVC.
|
interfaces can share a single PVC.
|
||||||
- ARP support (no InARP support in the kernel - there is an
|
- ARP support (no InARP support in the kernel - there is an
|
||||||
experimental InARP user-space daemon available on:
|
experimental InARP user-space daemon available on:
|
||||||
http://www.kernel.org/pub/linux/utils/net/hdlc/).
|
http://www.kernel.org/pub/linux/utils/net/hdlc/).
|
||||||
2. raw HDLC - either IP (IPv4) interface or Ethernet device emulation.
|
2. raw HDLC - either IP (IPv4) interface or Ethernet device emulation
|
||||||
3. Cisco HDLC.
|
3. Cisco HDLC
|
||||||
4. PPP (uses syncppp.c).
|
4. PPP
|
||||||
5. X.25 (uses X.25 routines).
|
5. X.25 (uses X.25 routines).
|
||||||
|
|
||||||
Generic HDLC is a protocol driver only - it needs a low-level driver
|
Generic HDLC is a protocol driver only - it needs a low-level driver
|
||||||
|
|
|
@ -27,6 +27,12 @@ min_adv_mss - INTEGER
|
||||||
The advertised MSS depends on the first hop route MTU, but will
|
The advertised MSS depends on the first hop route MTU, but will
|
||||||
never be lower than this setting.
|
never be lower than this setting.
|
||||||
|
|
||||||
|
rt_cache_rebuild_count - INTEGER
|
||||||
|
The per net-namespace route cache emergency rebuild threshold.
|
||||||
|
Any net-namespace having its route cache rebuilt due to
|
||||||
|
a hash bucket chain being too long more than this many times
|
||||||
|
will have its route caching disabled
|
||||||
|
|
||||||
IP Fragmentation:
|
IP Fragmentation:
|
||||||
|
|
||||||
ipfrag_high_thresh - INTEGER
|
ipfrag_high_thresh - INTEGER
|
||||||
|
|
|
@ -50,10 +50,6 @@ associates with the AP. hostapd and wpa_supplicant are used to take
|
||||||
care of WPA2-PSK authentication. In addition, hostapd is also
|
care of WPA2-PSK authentication. In addition, hostapd is also
|
||||||
processing access point side of association.
|
processing access point side of association.
|
||||||
|
|
||||||
Please note that the current Linux kernel does not enable AP mode, so a
|
|
||||||
simple patch is needed to enable AP mode selection:
|
|
||||||
http://johannes.sipsolutions.net/patches/kernel/all/LATEST/006-allow-ap-vlan-modes.patch
|
|
||||||
|
|
||||||
|
|
||||||
# Build mac80211_hwsim as part of kernel configuration
|
# Build mac80211_hwsim as part of kernel configuration
|
||||||
|
|
||||||
|
@ -65,3 +61,8 @@ hostapd hostapd.conf
|
||||||
|
|
||||||
# Run wpa_supplicant (station) for wlan1
|
# Run wpa_supplicant (station) for wlan1
|
||||||
wpa_supplicant -Dwext -iwlan1 -c wpa_supplicant.conf
|
wpa_supplicant -Dwext -iwlan1 -c wpa_supplicant.conf
|
||||||
|
|
||||||
|
|
||||||
|
More test cases are available in hostap.git:
|
||||||
|
git://w1.fi/srv/git/hostap.git and mac80211_hwsim/tests subdirectory
|
||||||
|
(http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=tree;f=mac80211_hwsim/tests)
|
||||||
|
|
|
@ -18,7 +18,7 @@ There are routines in net_init.c to handle the common cases of
|
||||||
alloc_etherdev, alloc_netdev. These reserve extra space for driver
|
alloc_etherdev, alloc_netdev. These reserve extra space for driver
|
||||||
private data which gets freed when the network device is freed. If
|
private data which gets freed when the network device is freed. If
|
||||||
separately allocated data is attached to the network device
|
separately allocated data is attached to the network device
|
||||||
(dev->priv) then it is up to the module exit handler to free that.
|
(netdev_priv(dev)) then it is up to the module exit handler to free that.
|
||||||
|
|
||||||
MTU
|
MTU
|
||||||
===
|
===
|
||||||
|
|
|
@ -131,11 +131,13 @@ are expected to do this during initialization.
|
||||||
|
|
||||||
r = zd_reg2alpha2(mac->regdomain, alpha2);
|
r = zd_reg2alpha2(mac->regdomain, alpha2);
|
||||||
if (!r)
|
if (!r)
|
||||||
regulatory_hint(hw->wiphy, alpha2, NULL);
|
regulatory_hint(hw->wiphy, alpha2);
|
||||||
|
|
||||||
Example code - drivers providing a built in regulatory domain:
|
Example code - drivers providing a built in regulatory domain:
|
||||||
--------------------------------------------------------------
|
--------------------------------------------------------------
|
||||||
|
|
||||||
|
[NOTE: This API is not currently available, it can be added when required]
|
||||||
|
|
||||||
If you have regulatory information you can obtain from your
|
If you have regulatory information you can obtain from your
|
||||||
driver and you *need* to use this we let you build a regulatory domain
|
driver and you *need* to use this we let you build a regulatory domain
|
||||||
structure and pass it to the wireless core. To do this you should
|
structure and pass it to the wireless core. To do this you should
|
||||||
|
@ -167,7 +169,6 @@ struct ieee80211_regdomain mydriver_jp_regdom = {
|
||||||
|
|
||||||
Then in some part of your code after your wiphy has been registered:
|
Then in some part of your code after your wiphy has been registered:
|
||||||
|
|
||||||
int r;
|
|
||||||
struct ieee80211_regdomain *rd;
|
struct ieee80211_regdomain *rd;
|
||||||
int size_of_regd;
|
int size_of_regd;
|
||||||
int num_rules = mydriver_jp_regdom.n_reg_rules;
|
int num_rules = mydriver_jp_regdom.n_reg_rules;
|
||||||
|
@ -182,13 +183,8 @@ Then in some part of your code after your wiphy has been registered:
|
||||||
|
|
||||||
memcpy(rd, &mydriver_jp_regdom, sizeof(struct ieee80211_regdomain));
|
memcpy(rd, &mydriver_jp_regdom, sizeof(struct ieee80211_regdomain));
|
||||||
|
|
||||||
for (i=0; i < num_rules; i++) {
|
for (i=0; i < num_rules; i++)
|
||||||
memcpy(&rd->reg_rules[i], &mydriver_jp_regdom.reg_rules[i],
|
memcpy(&rd->reg_rules[i],
|
||||||
|
&mydriver_jp_regdom.reg_rules[i],
|
||||||
sizeof(struct ieee80211_reg_rule));
|
sizeof(struct ieee80211_reg_rule));
|
||||||
}
|
regulatory_struct_hint(rd);
|
||||||
r = regulatory_hint(hw->wiphy, NULL, rd);
|
|
||||||
if (r) {
|
|
||||||
kfree(rd);
|
|
||||||
return r;
|
|
||||||
}
|
|
||||||
|
|
||||||
|
|
|
@ -540,7 +540,7 @@ A client would issue an operation by:
|
||||||
MSG_MORE should be set in msghdr::msg_flags on all but the last part of
|
MSG_MORE should be set in msghdr::msg_flags on all but the last part of
|
||||||
the request. Multiple requests may be made simultaneously.
|
the request. Multiple requests may be made simultaneously.
|
||||||
|
|
||||||
If a call is intended to go to a destination other then the default
|
If a call is intended to go to a destination other than the default
|
||||||
specified through connect(), then msghdr::msg_name should be set on the
|
specified through connect(), then msghdr::msg_name should be set on the
|
||||||
first request message of that call.
|
first request message of that call.
|
||||||
|
|
||||||
|
|
|
@ -118,7 +118,7 @@ As mentioned above, main purpose of TUN/TAP driver is tunneling.
|
||||||
It is used by VTun (http://vtun.sourceforge.net).
|
It is used by VTun (http://vtun.sourceforge.net).
|
||||||
|
|
||||||
Another interesting application using TUN/TAP is pipsecd
|
Another interesting application using TUN/TAP is pipsecd
|
||||||
(http://perso.enst.fr/~beyssac/pipsec/), an userspace IPSec
|
(http://perso.enst.fr/~beyssac/pipsec/), a userspace IPSec
|
||||||
implementation that can use complete kernel routing (unlike FreeS/WAN).
|
implementation that can use complete kernel routing (unlike FreeS/WAN).
|
||||||
|
|
||||||
3. How does Virtual network device actually work ?
|
3. How does Virtual network device actually work ?
|
||||||
|
|
|
@ -69,6 +69,11 @@ to the overall system performance.
|
||||||
On x86 nmi_watchdog is disabled by default so you have to enable it with
|
On x86 nmi_watchdog is disabled by default so you have to enable it with
|
||||||
a boot time parameter.
|
a boot time parameter.
|
||||||
|
|
||||||
|
It's possible to disable the NMI watchdog in run-time by writing "0" to
|
||||||
|
/proc/sys/kernel/nmi_watchdog. Writing "1" to the same file will re-enable
|
||||||
|
the NMI watchdog. Notice that you still need to use "nmi_watchdog=" parameter
|
||||||
|
at boot time.
|
||||||
|
|
||||||
NOTE: In kernels prior to 2.4.2-ac18 the NMI-oopser is enabled unconditionally
|
NOTE: In kernels prior to 2.4.2-ac18 the NMI-oopser is enabled unconditionally
|
||||||
on x86 SMP boxes.
|
on x86 SMP boxes.
|
||||||
|
|
||||||
|
|
|
@ -109,12 +109,18 @@ and it's also much more restricted in the latter case:
|
||||||
FURTHER NOTES ON NO-MMU MMAP
|
FURTHER NOTES ON NO-MMU MMAP
|
||||||
============================
|
============================
|
||||||
|
|
||||||
(*) A request for a private mapping of less than a page in size may not return
|
(*) A request for a private mapping of a file may return a buffer that is not
|
||||||
a page-aligned buffer. This is because the kernel calls kmalloc() to
|
page-aligned. This is because XIP may take place, and the data may not be
|
||||||
allocate the buffer, not get_free_page().
|
paged aligned in the backing store.
|
||||||
|
|
||||||
(*) A list of all the mappings on the system is visible through /proc/maps in
|
(*) A request for an anonymous mapping will always be page aligned. If
|
||||||
no-MMU mode.
|
possible the size of the request should be a power of two otherwise some
|
||||||
|
of the space may be wasted as the kernel must allocate a power-of-2
|
||||||
|
granule but will only discard the excess if appropriately configured as
|
||||||
|
this has an effect on fragmentation.
|
||||||
|
|
||||||
|
(*) A list of all the private copy and anonymous mappings on the system is
|
||||||
|
visible through /proc/maps in no-MMU mode.
|
||||||
|
|
||||||
(*) A list of all the mappings in use by a process is visible through
|
(*) A list of all the mappings in use by a process is visible through
|
||||||
/proc/<pid>/maps in no-MMU mode.
|
/proc/<pid>/maps in no-MMU mode.
|
||||||
|
@ -242,3 +248,18 @@ PROVIDING SHAREABLE BLOCK DEVICE SUPPORT
|
||||||
Provision of shared mappings on block device files is exactly the same as for
|
Provision of shared mappings on block device files is exactly the same as for
|
||||||
character devices. If there isn't a real device underneath, then the driver
|
character devices. If there isn't a real device underneath, then the driver
|
||||||
should allocate sufficient contiguous memory to honour any supported mapping.
|
should allocate sufficient contiguous memory to honour any supported mapping.
|
||||||
|
|
||||||
|
|
||||||
|
=================================
|
||||||
|
ADJUSTING PAGE TRIMMING BEHAVIOUR
|
||||||
|
=================================
|
||||||
|
|
||||||
|
NOMMU mmap automatically rounds up to the nearest power-of-2 number of pages
|
||||||
|
when performing an allocation. This can have adverse effects on memory
|
||||||
|
fragmentation, and as such, is left configurable. The default behaviour is to
|
||||||
|
aggressively trim allocations and discard any excess pages back in to the page
|
||||||
|
allocator. In order to retain finer-grained control over fragmentation, this
|
||||||
|
behaviour can either be disabled completely, or bumped up to a higher page
|
||||||
|
watermark where trimming begins.
|
||||||
|
|
||||||
|
Page trimming behaviour is configurable via the sysctl `vm.nr_trim_pages'.
|
||||||
|
|
|
@ -31,7 +31,7 @@ anyways).
|
||||||
|
|
||||||
After detecting the processor type, the kernel patches out sections of code
|
After detecting the processor type, the kernel patches out sections of code
|
||||||
that shouldn't be used by writing nop's over it. Using cpufeatures requires
|
that shouldn't be used by writing nop's over it. Using cpufeatures requires
|
||||||
just 2 macros (found in include/asm-ppc/cputable.h), as seen in head.S
|
just 2 macros (found in arch/powerpc/include/asm/cputable.h), as seen in head.S
|
||||||
transfer_to_handler:
|
transfer_to_handler:
|
||||||
|
|
||||||
#ifdef CONFIG_ALTIVEC
|
#ifdef CONFIG_ALTIVEC
|
||||||
|
|
|
@ -0,0 +1,39 @@
|
||||||
|
AMCC NDFC (NanD Flash Controller)
|
||||||
|
|
||||||
|
Required properties:
|
||||||
|
- compatible : "ibm,ndfc".
|
||||||
|
- reg : should specify chip select and size used for the chip (0x2000).
|
||||||
|
|
||||||
|
Optional properties:
|
||||||
|
- ccr : NDFC config and control register value (default 0).
|
||||||
|
- bank-settings : NDFC bank configuration register value (default 0).
|
||||||
|
|
||||||
|
Notes:
|
||||||
|
- partition(s) - follows the OF MTD standard for partitions
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
ndfc@1,0 {
|
||||||
|
compatible = "ibm,ndfc";
|
||||||
|
reg = <0x00000001 0x00000000 0x00002000>;
|
||||||
|
ccr = <0x00001000>;
|
||||||
|
bank-settings = <0x80002222>;
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <1>;
|
||||||
|
|
||||||
|
nand {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <1>;
|
||||||
|
|
||||||
|
partition@0 {
|
||||||
|
label = "kernel";
|
||||||
|
reg = <0x00000000 0x00200000>;
|
||||||
|
};
|
||||||
|
partition@200000 {
|
||||||
|
label = "root";
|
||||||
|
reg = <0x00200000 0x03E00000>;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
||||||
|
|
|
@ -18,7 +18,7 @@ This is the memory-mapped registers for on board FPGA.
|
||||||
|
|
||||||
Required properities:
|
Required properities:
|
||||||
- compatible : should be "fsl,fpga-pixis".
|
- compatible : should be "fsl,fpga-pixis".
|
||||||
- reg : should contain the address and the lenght of the FPPGA register
|
- reg : should contain the address and the length of the FPPGA register
|
||||||
set.
|
set.
|
||||||
|
|
||||||
Example (MPC8610HPCD):
|
Example (MPC8610HPCD):
|
||||||
|
@ -27,3 +27,33 @@ Example (MPC8610HPCD):
|
||||||
compatible = "fsl,fpga-pixis";
|
compatible = "fsl,fpga-pixis";
|
||||||
reg = <0xe8000000 32>;
|
reg = <0xe8000000 32>;
|
||||||
};
|
};
|
||||||
|
|
||||||
|
* Freescale BCSR GPIO banks
|
||||||
|
|
||||||
|
Some BCSR registers act as simple GPIO controllers, each such
|
||||||
|
register can be represented by the gpio-controller node.
|
||||||
|
|
||||||
|
Required properities:
|
||||||
|
- compatible : Should be "fsl,<board>-bcsr-gpio".
|
||||||
|
- reg : Should contain the address and the length of the GPIO bank
|
||||||
|
register.
|
||||||
|
- #gpio-cells : Should be two. The first cell is the pin number and the
|
||||||
|
second cell is used to specify optional paramters (currently unused).
|
||||||
|
- gpio-controller : Marks the port as GPIO controller.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
bcsr@1,0 {
|
||||||
|
#address-cells = <1>;
|
||||||
|
#size-cells = <1>;
|
||||||
|
compatible = "fsl,mpc8360mds-bcsr";
|
||||||
|
reg = <1 0 0x8000>;
|
||||||
|
ranges = <0 1 0 0x8000>;
|
||||||
|
|
||||||
|
bcsr13: gpio-controller@d {
|
||||||
|
#gpio-cells = <2>;
|
||||||
|
compatible = "fsl,mpc8360mds-bcsr-gpio";
|
||||||
|
reg = <0xd 1>;
|
||||||
|
gpio-controller;
|
||||||
|
};
|
||||||
|
};
|
||||||
|
|
|
@ -2,8 +2,8 @@
|
||||||
|
|
||||||
The MDIO is a bus to which the PHY devices are connected. For each
|
The MDIO is a bus to which the PHY devices are connected. For each
|
||||||
device that exists on this bus, a child node should be created. See
|
device that exists on this bus, a child node should be created. See
|
||||||
the definition of the PHY node below for an example of how to define
|
the definition of the PHY node in booting-without-of.txt for an example
|
||||||
a PHY.
|
of how to define a PHY.
|
||||||
|
|
||||||
Required properties:
|
Required properties:
|
||||||
- reg : Offset and length of the register set for the device
|
- reg : Offset and length of the register set for the device
|
||||||
|
@ -21,6 +21,14 @@ Example:
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
|
* TBI Internal MDIO bus
|
||||||
|
|
||||||
|
As of this writing, every tsec is associated with an internal TBI PHY.
|
||||||
|
This PHY is accessed through the local MDIO bus. These buses are defined
|
||||||
|
similarly to the mdio buses, except they are compatible with "fsl,gianfar-tbi".
|
||||||
|
The TBI PHYs underneath them are similar to normal PHYs, but the reg property
|
||||||
|
is considered instructive, rather than descriptive. The reg property should
|
||||||
|
be chosen so it doesn't interfere with other PHYs on the bus.
|
||||||
|
|
||||||
* Gianfar-compatible ethernet nodes
|
* Gianfar-compatible ethernet nodes
|
||||||
|
|
||||||
|
|
|
@ -191,12 +191,20 @@ Userspace input handlers (uevents) or kernel input handlers (rfkill-input):
|
||||||
to tell the devices registered with the rfkill class to change
|
to tell the devices registered with the rfkill class to change
|
||||||
their state (i.e. translates the input layer event into real
|
their state (i.e. translates the input layer event into real
|
||||||
action).
|
action).
|
||||||
|
|
||||||
* rfkill-input implements EPO by handling EV_SW SW_RFKILL_ALL 0
|
* rfkill-input implements EPO by handling EV_SW SW_RFKILL_ALL 0
|
||||||
(power off all transmitters) in a special way: it ignores any
|
(power off all transmitters) in a special way: it ignores any
|
||||||
overrides and local state cache and forces all transmitters to the
|
overrides and local state cache and forces all transmitters to the
|
||||||
RFKILL_STATE_SOFT_BLOCKED state (including those which are already
|
RFKILL_STATE_SOFT_BLOCKED state (including those which are already
|
||||||
supposed to be BLOCKED). Note that the opposite event (power on all
|
supposed to be BLOCKED).
|
||||||
transmitters) is handled normally.
|
* rfkill EPO will remain active until rfkill-input receives an
|
||||||
|
EV_SW SW_RFKILL_ALL 1 event. While the EPO is active, transmitters
|
||||||
|
are locked in the blocked state (rfkill will refuse to unblock them).
|
||||||
|
* rfkill-input implements different policies that the user can
|
||||||
|
select for handling EV_SW SW_RFKILL_ALL 1. It will unlock rfkill,
|
||||||
|
and either do nothing (leave transmitters blocked, but now unlocked),
|
||||||
|
restore the transmitters to their state before the EPO, or unblock
|
||||||
|
them all.
|
||||||
|
|
||||||
Userspace uevent handler or kernel platform-specific drivers hooked to the
|
Userspace uevent handler or kernel platform-specific drivers hooked to the
|
||||||
rfkill notifier chain:
|
rfkill notifier chain:
|
||||||
|
@ -331,11 +339,9 @@ class to get a sysfs interface :-)
|
||||||
correct event for your switch/button. These events are emergency power-off
|
correct event for your switch/button. These events are emergency power-off
|
||||||
events when they are trying to turn the transmitters off. An example of an
|
events when they are trying to turn the transmitters off. An example of an
|
||||||
input device which SHOULD generate *_RFKILL_ALL events is the wireless-kill
|
input device which SHOULD generate *_RFKILL_ALL events is the wireless-kill
|
||||||
switch in a laptop which is NOT a hotkey, but a real switch that kills radios
|
switch in a laptop which is NOT a hotkey, but a real sliding/rocker switch.
|
||||||
in hardware, even if the O.S. has gone to lunch. An example of an input device
|
An example of an input device which SHOULD NOT generate *_RFKILL_ALL events by
|
||||||
which SHOULD NOT generate *_RFKILL_ALL events by default, is any sort of hot
|
default, is any sort of hot key that is type-specific (e.g. the one for WLAN).
|
||||||
key that does nothing by itself, as well as any hot key that is type-specific
|
|
||||||
(e.g. the one for WLAN).
|
|
||||||
|
|
||||||
|
|
||||||
3.1 Guidelines for wireless device drivers
|
3.1 Guidelines for wireless device drivers
|
||||||
|
|
|
@ -1402,7 +1402,7 @@ Syscalls are implemented on Linux for S390 by the Supervisor call instruction (S
|
||||||
possibilities of these as the instruction is made up of a 0xA opcode & the second byte being
|
possibilities of these as the instruction is made up of a 0xA opcode & the second byte being
|
||||||
the syscall number. They are traced using the simple command.
|
the syscall number. They are traced using the simple command.
|
||||||
TR SVC <Optional value or range>
|
TR SVC <Optional value or range>
|
||||||
the syscalls are defined in linux/include/asm-s390/unistd.h
|
the syscalls are defined in linux/arch/s390/include/asm/unistd.h
|
||||||
e.g. to trace all file opens just do
|
e.g. to trace all file opens just do
|
||||||
TR SVC 5 ( as this is the syscall number of open )
|
TR SVC 5 ( as this is the syscall number of open )
|
||||||
|
|
||||||
|
|
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче