aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/00-INDEX24
-rw-r--r--Documentation/ABI/testing/sysfs-kernel-uids2
-rw-r--r--Documentation/DocBook/genericirq.tmpl26
-rw-r--r--Documentation/DocBook/lsm.tmpl2
-rw-r--r--Documentation/DocBook/mtdnand.tmpl58
-rw-r--r--Documentation/DocBook/procfs-guide.tmpl16
-rw-r--r--Documentation/DocBook/rapidio.tmpl18
-rw-r--r--Documentation/DocBook/videobook.tmpl34
-rw-r--r--Documentation/DocBook/z8530book.tmpl12
-rw-r--r--Documentation/cgroups.txt22
-rw-r--r--Documentation/controllers/memory.txt279
-rw-r--r--Documentation/cpusets.txt23
-rw-r--r--Documentation/edac.txt (renamed from Documentation/drivers/edac/edac.txt)0
-rw-r--r--Documentation/email-clients.txt1
-rw-r--r--Documentation/feature-removal-schedule.txt8
-rw-r--r--Documentation/filesystems/00-INDEX4
-rw-r--r--Documentation/filesystems/Locking3
-rw-r--r--Documentation/filesystems/dnotify.txt (renamed from Documentation/dnotify.txt)10
-rw-r--r--Documentation/filesystems/porting30
-rw-r--r--Documentation/filesystems/sharedsubtree.txt (renamed from Documentation/sharedsubtree.txt)0
-rw-r--r--Documentation/filesystems/vfs.txt17
-rw-r--r--Documentation/leds-class.txt29
-rw-r--r--Documentation/powerpc/booting-without-of.txt42
-rw-r--r--Documentation/scheduler/00-INDEX16
-rw-r--r--Documentation/scheduler/sched-arch.txt (renamed from Documentation/sched-arch.txt)0
-rw-r--r--Documentation/scheduler/sched-coding.txt (renamed from Documentation/sched-coding.txt)0
-rw-r--r--Documentation/scheduler/sched-design-CFS.txt (renamed from Documentation/sched-design-CFS.txt)0
-rw-r--r--Documentation/scheduler/sched-design.txt (renamed from Documentation/sched-design.txt)0
-rw-r--r--Documentation/scheduler/sched-domains.txt (renamed from Documentation/sched-domains.txt)0
-rw-r--r--Documentation/scheduler/sched-nice-design.txt (renamed from Documentation/sched-nice-design.txt)0
-rw-r--r--Documentation/scheduler/sched-stats.txt (renamed from Documentation/sched-stats.txt)0
-rw-r--r--Documentation/sysctl/vm.txt22
32 files changed, 520 insertions, 178 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 33f55917f23f..6e9c4050a41b 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -129,18 +129,16 @@ devices.txt
129 - plain ASCII listing of all the nodes in /dev/ with major minor #'s. 129 - plain ASCII listing of all the nodes in /dev/ with major minor #'s.
130digiepca.txt 130digiepca.txt
131 - info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards. 131 - info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards.
132dnotify.txt
133 - info about directory notification in Linux.
134dontdiff 132dontdiff
135 - file containing a list of files that should never be diff'ed. 133 - file containing a list of files that should never be diff'ed.
136driver-model/ 134driver-model/
137 - directory with info about Linux driver model. 135 - directory with info about Linux driver model.
138drivers/
139 - directory with driver documentation (currently only EDAC).
140dvb/ 136dvb/
141 - info on Linux Digital Video Broadcast (DVB) subsystem. 137 - info on Linux Digital Video Broadcast (DVB) subsystem.
142early-userspace/ 138early-userspace/
143 - info about initramfs, klibc, and userspace early during boot. 139 - info about initramfs, klibc, and userspace early during boot.
140edac.txt
141 - information on EDAC - Error Detection And Correction
144eisa.txt 142eisa.txt
145 - info on EISA bus support. 143 - info on EISA bus support.
146exception.txt 144exception.txt
@@ -337,20 +335,8 @@ rtc.txt
337 - notes on how to use the Real Time Clock (aka CMOS clock) driver. 335 - notes on how to use the Real Time Clock (aka CMOS clock) driver.
338s390/ 336s390/
339 - directory with info on using Linux on the IBM S390. 337 - directory with info on using Linux on the IBM S390.
340sched-arch.txt 338scheduler/
341 - CPU Scheduler implementation hints for architecture specific code. 339 - directory with info on the scheduler.
342sched-coding.txt
343 - reference for various scheduler-related methods in the O(1) scheduler.
344sched-design.txt
345 - goals, design and implementation of the Linux O(1) scheduler.
346sched-design-CFS.txt
347 - goals, design and implementation of the Complete Fair Scheduler.
348sched-domains.txt
349 - information on scheduling domains.
350sched-nice-design.txt
351 - How and why the scheduler's nice levels are implemented.
352sched-stats.txt
353 - information on schedstats (Linux Scheduler Statistics).
354scsi/ 340scsi/
355 - directory with info on Linux scsi support. 341 - directory with info on Linux scsi support.
356serial/ 342serial/
@@ -363,8 +349,6 @@ sgi-visws.txt
363 - short blurb on the SGI Visual Workstations. 349 - short blurb on the SGI Visual Workstations.
364sh/ 350sh/
365 - directory with info on porting Linux to a new architecture. 351 - directory with info on porting Linux to a new architecture.
366sharedsubtree.txt
367 - a description of shared subtrees for namespaces.
368smart-config.txt 352smart-config.txt
369 - description of the Smart Config makefile feature. 353 - description of the Smart Config makefile feature.
370sony-laptop.txt 354sony-laptop.txt
diff --git a/Documentation/ABI/testing/sysfs-kernel-uids b/Documentation/ABI/testing/sysfs-kernel-uids
index 648d65dbc0e7..28f14695a852 100644
--- a/Documentation/ABI/testing/sysfs-kernel-uids
+++ b/Documentation/ABI/testing/sysfs-kernel-uids
@@ -11,4 +11,4 @@ Description:
11 example would be, if User A has shares = 1024 and user 11 example would be, if User A has shares = 1024 and user
12 B has shares = 2048, User B will get twice the CPU 12 B has shares = 2048, User B will get twice the CPU
13 bandwidth user A will. For more details refer 13 bandwidth user A will. For more details refer
14 Documentation/sched-design-CFS.txt 14 Documentation/scheduler/sched-design-CFS.txt
diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl
index 4215f69ce7e6..3a882d9a90a9 100644
--- a/Documentation/DocBook/genericirq.tmpl
+++ b/Documentation/DocBook/genericirq.tmpl
@@ -172,7 +172,7 @@
172 <listitem><para>Chiplevel hardware encapsulation</para></listitem> 172 <listitem><para>Chiplevel hardware encapsulation</para></listitem>
173 </orderedlist> 173 </orderedlist>
174 </para> 174 </para>
175 <sect1> 175 <sect1 id="Interrupt_control_flow">
176 <title>Interrupt control flow</title> 176 <title>Interrupt control flow</title>
177 <para> 177 <para>
178 Each interrupt is described by an interrupt descriptor structure 178 Each interrupt is described by an interrupt descriptor structure
@@ -190,7 +190,7 @@
190 referenced by the assigned chip descriptor structure. 190 referenced by the assigned chip descriptor structure.
191 </para> 191 </para>
192 </sect1> 192 </sect1>
193 <sect1> 193 <sect1 id="Highlevel_Driver_API">
194 <title>Highlevel Driver API</title> 194 <title>Highlevel Driver API</title>
195 <para> 195 <para>
196 The highlevel Driver API consists of following functions: 196 The highlevel Driver API consists of following functions:
@@ -210,7 +210,7 @@
210 See the autogenerated function documentation for details. 210 See the autogenerated function documentation for details.
211 </para> 211 </para>
212 </sect1> 212 </sect1>
213 <sect1> 213 <sect1 id="Highlevel_IRQ_flow_handlers">
214 <title>Highlevel IRQ flow handlers</title> 214 <title>Highlevel IRQ flow handlers</title>
215 <para> 215 <para>
216 The generic layer provides a set of pre-defined irq-flow methods: 216 The generic layer provides a set of pre-defined irq-flow methods:
@@ -224,9 +224,9 @@
224 specific) are assigned to specific interrupts by the architecture 224 specific) are assigned to specific interrupts by the architecture
225 either during bootup or during device initialization. 225 either during bootup or during device initialization.
226 </para> 226 </para>
227 <sect2> 227 <sect2 id="Default_flow_implementations">
228 <title>Default flow implementations</title> 228 <title>Default flow implementations</title>
229 <sect3> 229 <sect3 id="Helper_functions">
230 <title>Helper functions</title> 230 <title>Helper functions</title>
231 <para> 231 <para>
232 The helper functions call the chip primitives and 232 The helper functions call the chip primitives and
@@ -267,9 +267,9 @@ noop(irq)
267 </para> 267 </para>
268 </sect3> 268 </sect3>
269 </sect2> 269 </sect2>
270 <sect2> 270 <sect2 id="Default_flow_handler_implementations">
271 <title>Default flow handler implementations</title> 271 <title>Default flow handler implementations</title>
272 <sect3> 272 <sect3 id="Default_Level_IRQ_flow_handler">
273 <title>Default Level IRQ flow handler</title> 273 <title>Default Level IRQ flow handler</title>
274 <para> 274 <para>
275 handle_level_irq provides a generic implementation 275 handle_level_irq provides a generic implementation
@@ -284,7 +284,7 @@ desc->chip->end();
284 </programlisting> 284 </programlisting>
285 </para> 285 </para>
286 </sect3> 286 </sect3>
287 <sect3> 287 <sect3 id="Default_Edge_IRQ_flow_handler">
288 <title>Default Edge IRQ flow handler</title> 288 <title>Default Edge IRQ flow handler</title>
289 <para> 289 <para>
290 handle_edge_irq provides a generic implementation 290 handle_edge_irq provides a generic implementation
@@ -311,7 +311,7 @@ desc->chip->end();
311 </programlisting> 311 </programlisting>
312 </para> 312 </para>
313 </sect3> 313 </sect3>
314 <sect3> 314 <sect3 id="Default_simple_IRQ_flow_handler">
315 <title>Default simple IRQ flow handler</title> 315 <title>Default simple IRQ flow handler</title>
316 <para> 316 <para>
317 handle_simple_irq provides a generic implementation 317 handle_simple_irq provides a generic implementation
@@ -328,7 +328,7 @@ handle_IRQ_event(desc->action);
328 </programlisting> 328 </programlisting>
329 </para> 329 </para>
330 </sect3> 330 </sect3>
331 <sect3> 331 <sect3 id="Default_per_CPU_flow_handler">
332 <title>Default per CPU flow handler</title> 332 <title>Default per CPU flow handler</title>
333 <para> 333 <para>
334 handle_percpu_irq provides a generic implementation 334 handle_percpu_irq provides a generic implementation
@@ -349,7 +349,7 @@ desc->chip->end();
349 </para> 349 </para>
350 </sect3> 350 </sect3>
351 </sect2> 351 </sect2>
352 <sect2> 352 <sect2 id="Quirks_and_optimizations">
353 <title>Quirks and optimizations</title> 353 <title>Quirks and optimizations</title>
354 <para> 354 <para>
355 The generic functions are intended for 'clean' architectures and chips, 355 The generic functions are intended for 'clean' architectures and chips,
@@ -358,7 +358,7 @@ desc->chip->end();
358 overriding the highlevel irq-flow handler. 358 overriding the highlevel irq-flow handler.
359 </para> 359 </para>
360 </sect2> 360 </sect2>
361 <sect2> 361 <sect2 id="Delayed_interrupt_disable">
362 <title>Delayed interrupt disable</title> 362 <title>Delayed interrupt disable</title>
363 <para> 363 <para>
364 This per interrupt selectable feature, which was introduced by Russell 364 This per interrupt selectable feature, which was introduced by Russell
@@ -380,7 +380,7 @@ desc->chip->end();
380 </para> 380 </para>
381 </sect2> 381 </sect2>
382 </sect1> 382 </sect1>
383 <sect1> 383 <sect1 id="Chiplevel_hardware_encapsulation">
384 <title>Chiplevel hardware encapsulation</title> 384 <title>Chiplevel hardware encapsulation</title>
385 <para> 385 <para>
386 The chip level hardware descriptor structure irq_chip 386 The chip level hardware descriptor structure irq_chip
diff --git a/Documentation/DocBook/lsm.tmpl b/Documentation/DocBook/lsm.tmpl
index f63822195871..fe7664ce9667 100644
--- a/Documentation/DocBook/lsm.tmpl
+++ b/Documentation/DocBook/lsm.tmpl
@@ -33,7 +33,7 @@
33 </authorgroup> 33 </authorgroup>
34 </articleinfo> 34 </articleinfo>
35 35
36<sect1><title>Introduction</title> 36<sect1 id="Introduction"><title>Introduction</title>
37 37
38<para> 38<para>
39In March 2001, the National Security Agency (NSA) gave a presentation 39In March 2001, the National Security Agency (NSA) gave a presentation
diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl
index 957cf5c26831..8e145857fc9d 100644
--- a/Documentation/DocBook/mtdnand.tmpl
+++ b/Documentation/DocBook/mtdnand.tmpl
@@ -80,7 +80,7 @@
80 struct member has a short description which is marked with an [XXX] identifier. 80 struct member has a short description which is marked with an [XXX] identifier.
81 The following chapters explain the meaning of those identifiers. 81 The following chapters explain the meaning of those identifiers.
82 </para> 82 </para>
83 <sect1> 83 <sect1 id="Function_identifiers_XXX">
84 <title>Function identifiers [XXX]</title> 84 <title>Function identifiers [XXX]</title>
85 <para> 85 <para>
86 The functions are marked with [XXX] identifiers in the short 86 The functions are marked with [XXX] identifiers in the short
@@ -115,7 +115,7 @@
115 </para></listitem> 115 </para></listitem>
116 </itemizedlist> 116 </itemizedlist>
117 </sect1> 117 </sect1>
118 <sect1> 118 <sect1 id="Struct_member_identifiers_XXX">
119 <title>Struct member identifiers [XXX]</title> 119 <title>Struct member identifiers [XXX]</title>
120 <para> 120 <para>
121 The struct members are marked with [XXX] identifiers in the 121 The struct members are marked with [XXX] identifiers in the
@@ -159,7 +159,7 @@
159 basic functions and fill out some really board dependent 159 basic functions and fill out some really board dependent
160 members in the nand chip description structure. 160 members in the nand chip description structure.
161 </para> 161 </para>
162 <sect1> 162 <sect1 id="Basic_defines">
163 <title>Basic defines</title> 163 <title>Basic defines</title>
164 <para> 164 <para>
165 At least you have to provide a mtd structure and 165 At least you have to provide a mtd structure and
@@ -185,7 +185,7 @@ static struct nand_chip board_chip;
185static unsigned long baseaddr; 185static unsigned long baseaddr;
186 </programlisting> 186 </programlisting>
187 </sect1> 187 </sect1>
188 <sect1> 188 <sect1 id="Partition_defines">
189 <title>Partition defines</title> 189 <title>Partition defines</title>
190 <para> 190 <para>
191 If you want to divide your device into partitions, then 191 If you want to divide your device into partitions, then
@@ -204,7 +204,7 @@ static struct mtd_partition partition_info[] = {
204}; 204};
205 </programlisting> 205 </programlisting>
206 </sect1> 206 </sect1>
207 <sect1> 207 <sect1 id="Hardware_control_functions">
208 <title>Hardware control function</title> 208 <title>Hardware control function</title>
209 <para> 209 <para>
210 The hardware control function provides access to the 210 The hardware control function provides access to the
@@ -246,7 +246,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd)
246} 246}
247 </programlisting> 247 </programlisting>
248 </sect1> 248 </sect1>
249 <sect1> 249 <sect1 id="Device_ready_function">
250 <title>Device ready function</title> 250 <title>Device ready function</title>
251 <para> 251 <para>
252 If the hardware interface has the ready busy pin of the NAND chip connected to a 252 If the hardware interface has the ready busy pin of the NAND chip connected to a
@@ -257,7 +257,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd)
257 the function must not be defined and the function pointer this->dev_ready is set to NULL. 257 the function must not be defined and the function pointer this->dev_ready is set to NULL.
258 </para> 258 </para>
259 </sect1> 259 </sect1>
260 <sect1> 260 <sect1 id="Init_function">
261 <title>Init function</title> 261 <title>Init function</title>
262 <para> 262 <para>
263 The init function allocates memory and sets up all the board 263 The init function allocates memory and sets up all the board
@@ -325,7 +325,7 @@ out:
325module_init(board_init); 325module_init(board_init);
326 </programlisting> 326 </programlisting>
327 </sect1> 327 </sect1>
328 <sect1> 328 <sect1 id="Exit_function">
329 <title>Exit function</title> 329 <title>Exit function</title>
330 <para> 330 <para>
331 The exit function is only neccecary if the driver is 331 The exit function is only neccecary if the driver is
@@ -359,7 +359,7 @@ module_exit(board_cleanup);
359 driver. For a list of functions which can be overridden by the board 359 driver. For a list of functions which can be overridden by the board
360 driver see the documentation of the nand_chip structure. 360 driver see the documentation of the nand_chip structure.
361 </para> 361 </para>
362 <sect1> 362 <sect1 id="Multiple_chip_control">
363 <title>Multiple chip control</title> 363 <title>Multiple chip control</title>
364 <para> 364 <para>
365 The nand driver can control chip arrays. Therefor the 365 The nand driver can control chip arrays. Therefor the
@@ -419,9 +419,9 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
419} 419}
420 </programlisting> 420 </programlisting>
421 </sect1> 421 </sect1>
422 <sect1> 422 <sect1 id="Hardware_ECC_support">
423 <title>Hardware ECC support</title> 423 <title>Hardware ECC support</title>
424 <sect2> 424 <sect2 id="Functions_and_constants">
425 <title>Functions and constants</title> 425 <title>Functions and constants</title>
426 <para> 426 <para>
427 The nand driver supports three different types of 427 The nand driver supports three different types of
@@ -475,7 +475,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
475 </itemizedlist> 475 </itemizedlist>
476 </para> 476 </para>
477 </sect2> 477 </sect2>
478 <sect2> 478 <sect2 id="Hardware_ECC_with_syndrome_calculation">
479 <title>Hardware ECC with syndrome calculation</title> 479 <title>Hardware ECC with syndrome calculation</title>
480 <para> 480 <para>
481 Many hardware ECC implementations provide Reed-Solomon 481 Many hardware ECC implementations provide Reed-Solomon
@@ -500,7 +500,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
500 </para> 500 </para>
501 </sect2> 501 </sect2>
502 </sect1> 502 </sect1>
503 <sect1> 503 <sect1 id="Bad_Block_table_support">
504 <title>Bad block table support</title> 504 <title>Bad block table support</title>
505 <para> 505 <para>
506 Most NAND chips mark the bad blocks at a defined 506 Most NAND chips mark the bad blocks at a defined
@@ -552,7 +552,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
552 allows faster access than always checking the 552 allows faster access than always checking the
553 bad block information on the flash chip itself. 553 bad block information on the flash chip itself.
554 </para> 554 </para>
555 <sect2> 555 <sect2 id="Flash_based_tables">
556 <title>Flash based tables</title> 556 <title>Flash based tables</title>
557 <para> 557 <para>
558 It may be desired or neccecary to keep a bad block table in FLASH. 558 It may be desired or neccecary to keep a bad block table in FLASH.
@@ -587,7 +587,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
587 </itemizedlist> 587 </itemizedlist>
588 </para> 588 </para>
589 </sect2> 589 </sect2>
590 <sect2> 590 <sect2 id="User_defined_tables">
591 <title>User defined tables</title> 591 <title>User defined tables</title>
592 <para> 592 <para>
593 User defined tables are created by filling out a 593 User defined tables are created by filling out a
@@ -676,7 +676,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
676 </para> 676 </para>
677 </sect2> 677 </sect2>
678 </sect1> 678 </sect1>
679 <sect1> 679 <sect1 id="Spare_area_placement">
680 <title>Spare area (auto)placement</title> 680 <title>Spare area (auto)placement</title>
681 <para> 681 <para>
682 The nand driver implements different possibilities for 682 The nand driver implements different possibilities for
@@ -730,7 +730,7 @@ struct nand_oobinfo {
730 </para></listitem> 730 </para></listitem>
731 </itemizedlist> 731 </itemizedlist>
732 </para> 732 </para>
733 <sect2> 733 <sect2 id="Placement_defined_by_fs_driver">
734 <title>Placement defined by fs driver</title> 734 <title>Placement defined by fs driver</title>
735 <para> 735 <para>
736 The calling function provides a pointer to a nand_oobinfo 736 The calling function provides a pointer to a nand_oobinfo
@@ -760,7 +760,7 @@ struct nand_oobinfo {
760 done according to the given scheme in the nand_oobinfo structure. 760 done according to the given scheme in the nand_oobinfo structure.
761 </para> 761 </para>
762 </sect2> 762 </sect2>
763 <sect2> 763 <sect2 id="Automatic_placement">
764 <title>Automatic placement</title> 764 <title>Automatic placement</title>
765 <para> 765 <para>
766 Automatic placement uses the built in defaults to place the 766 Automatic placement uses the built in defaults to place the
@@ -774,7 +774,7 @@ struct nand_oobinfo {
774 done according to the default builtin scheme. 774 done according to the default builtin scheme.
775 </para> 775 </para>
776 </sect2> 776 </sect2>
777 <sect2> 777 <sect2 id="User_space_placement_selection">
778 <title>User space placement selection</title> 778 <title>User space placement selection</title>
779 <para> 779 <para>
780 All non ecc functions like mtd->read and mtd->write use an internal 780 All non ecc functions like mtd->read and mtd->write use an internal
@@ -789,9 +789,9 @@ struct nand_oobinfo {
789 </para> 789 </para>
790 </sect2> 790 </sect2>
791 </sect1> 791 </sect1>
792 <sect1> 792 <sect1 id="Spare_area_autoplacement_default">
793 <title>Spare area autoplacement default schemes</title> 793 <title>Spare area autoplacement default schemes</title>
794 <sect2> 794 <sect2 id="pagesize_256">
795 <title>256 byte pagesize</title> 795 <title>256 byte pagesize</title>
796<informaltable><tgroup cols="3"><tbody> 796<informaltable><tgroup cols="3"><tbody>
797<row> 797<row>
@@ -843,7 +843,7 @@ pages this byte is reserved</entry>
843</row> 843</row>
844</tbody></tgroup></informaltable> 844</tbody></tgroup></informaltable>
845 </sect2> 845 </sect2>
846 <sect2> 846 <sect2 id="pagesize_512">
847 <title>512 byte pagesize</title> 847 <title>512 byte pagesize</title>
848<informaltable><tgroup cols="3"><tbody> 848<informaltable><tgroup cols="3"><tbody>
849<row> 849<row>
@@ -906,7 +906,7 @@ in this page</entry>
906</row> 906</row>
907</tbody></tgroup></informaltable> 907</tbody></tgroup></informaltable>
908 </sect2> 908 </sect2>
909 <sect2> 909 <sect2 id="pagesize_2048">
910 <title>2048 byte pagesize</title> 910 <title>2048 byte pagesize</title>
911<informaltable><tgroup cols="3"><tbody> 911<informaltable><tgroup cols="3"><tbody>
912<row> 912<row>
@@ -1126,9 +1126,9 @@ in this page</entry>
1126 <para> 1126 <para>
1127 This chapter describes the constants which might be relevant for a driver developer. 1127 This chapter describes the constants which might be relevant for a driver developer.
1128 </para> 1128 </para>
1129 <sect1> 1129 <sect1 id="Chip_option_constants">
1130 <title>Chip option constants</title> 1130 <title>Chip option constants</title>
1131 <sect2> 1131 <sect2 id="Constants_for_chip_id_table">
1132 <title>Constants for chip id table</title> 1132 <title>Constants for chip id table</title>
1133 <para> 1133 <para>
1134 These constants are defined in nand.h. They are ored together to describe 1134 These constants are defined in nand.h. They are ored together to describe
@@ -1153,7 +1153,7 @@ in this page</entry>
1153 </programlisting> 1153 </programlisting>
1154 </para> 1154 </para>
1155 </sect2> 1155 </sect2>
1156 <sect2> 1156 <sect2 id="Constants_for_runtime_options">
1157 <title>Constants for runtime options</title> 1157 <title>Constants for runtime options</title>
1158 <para> 1158 <para>
1159 These constants are defined in nand.h. They are ored together to describe 1159 These constants are defined in nand.h. They are ored together to describe
@@ -1171,7 +1171,7 @@ in this page</entry>
1171 </sect2> 1171 </sect2>
1172 </sect1> 1172 </sect1>
1173 1173
1174 <sect1> 1174 <sect1 id="EEC_selection_constants">
1175 <title>ECC selection constants</title> 1175 <title>ECC selection constants</title>
1176 <para> 1176 <para>
1177 Use these constants to select the ECC algorithm. 1177 Use these constants to select the ECC algorithm.
@@ -1192,7 +1192,7 @@ in this page</entry>
1192 </para> 1192 </para>
1193 </sect1> 1193 </sect1>
1194 1194
1195 <sect1> 1195 <sect1 id="Hardware_control_related_constants">
1196 <title>Hardware control related constants</title> 1196 <title>Hardware control related constants</title>
1197 <para> 1197 <para>
1198 These constants describe the requested hardware access function when 1198 These constants describe the requested hardware access function when
@@ -1218,7 +1218,7 @@ in this page</entry>
1218 </para> 1218 </para>
1219 </sect1> 1219 </sect1>
1220 1220
1221 <sect1> 1221 <sect1 id="Bad_block_table_constants">
1222 <title>Bad block table related constants</title> 1222 <title>Bad block table related constants</title>
1223 <para> 1223 <para>
1224 These constants describe the options used for bad block 1224 These constants describe the options used for bad block
diff --git a/Documentation/DocBook/procfs-guide.tmpl b/Documentation/DocBook/procfs-guide.tmpl
index 2de84dc195a8..1fd6a1ec7591 100644
--- a/Documentation/DocBook/procfs-guide.tmpl
+++ b/Documentation/DocBook/procfs-guide.tmpl
@@ -85,7 +85,7 @@
85 85
86 86
87 87
88 <preface> 88 <preface id="Preface">
89 <title>Preface</title> 89 <title>Preface</title>
90 90
91 <para> 91 <para>
@@ -230,7 +230,7 @@
230 230
231 231
232 232
233 <sect1> 233 <sect1 id="Creating_a_symlink">
234 <title>Creating a symlink</title> 234 <title>Creating a symlink</title>
235 235
236 <funcsynopsis> 236 <funcsynopsis>
@@ -254,7 +254,7 @@
254 </para> 254 </para>
255 </sect1> 255 </sect1>
256 256
257 <sect1> 257 <sect1 id="Creating_a_directory">
258 <title>Creating a directory</title> 258 <title>Creating a directory</title>
259 259
260 <funcsynopsis> 260 <funcsynopsis>
@@ -274,7 +274,7 @@
274 274
275 275
276 276
277 <sect1> 277 <sect1 id="Removing_an_entry">
278 <title>Removing an entry</title> 278 <title>Removing an entry</title>
279 279
280 <funcsynopsis> 280 <funcsynopsis>
@@ -340,7 +340,7 @@ entry->write_proc = write_proc_foo;
340 340
341 341
342 342
343 <sect1> 343 <sect1 id="Reading_data">
344 <title>Reading data</title> 344 <title>Reading data</title>
345 345
346 <para> 346 <para>
@@ -448,7 +448,7 @@ entry->write_proc = write_proc_foo;
448 448
449 449
450 450
451 <sect1> 451 <sect1 id="Writing_data">
452 <title>Writing data</title> 452 <title>Writing data</title>
453 453
454 <para> 454 <para>
@@ -579,7 +579,7 @@ int foo_read_func(char *page, char **start, off_t off,
579 579
580 580
581 581
582 <sect1> 582 <sect1 id="Modules">
583 <title>Modules</title> 583 <title>Modules</title>
584 584
585 <para> 585 <para>
@@ -599,7 +599,7 @@ entry->owner = THIS_MODULE;
599 599
600 600
601 601
602 <sect1> 602 <sect1 id="Mode_and_ownership">
603 <title>Mode and ownership</title> 603 <title>Mode and ownership</title>
604 604
605 <para> 605 <para>
diff --git a/Documentation/DocBook/rapidio.tmpl b/Documentation/DocBook/rapidio.tmpl
index a8b88c47e809..b9e143e28c64 100644
--- a/Documentation/DocBook/rapidio.tmpl
+++ b/Documentation/DocBook/rapidio.tmpl
@@ -77,11 +77,11 @@
77 <chapter id="bugs"> 77 <chapter id="bugs">
78 <title>Known Bugs and Limitations</title> 78 <title>Known Bugs and Limitations</title>
79 79
80 <sect1> 80 <sect1 id="known_bugs">
81 <title>Bugs</title> 81 <title>Bugs</title>
82 <para>None. ;)</para> 82 <para>None. ;)</para>
83 </sect1> 83 </sect1>
84 <sect1> 84 <sect1 id="Limitations">
85 <title>Limitations</title> 85 <title>Limitations</title>
86 <para> 86 <para>
87 <orderedlist> 87 <orderedlist>
@@ -100,7 +100,7 @@
100 on devices, request/map memory region resources, 100 on devices, request/map memory region resources,
101 and manage mailboxes/doorbells. 101 and manage mailboxes/doorbells.
102 </para> 102 </para>
103 <sect1> 103 <sect1 id="Functions">
104 <title>Functions</title> 104 <title>Functions</title>
105!Iinclude/linux/rio_drv.h 105!Iinclude/linux/rio_drv.h
106!Edrivers/rapidio/rio-driver.c 106!Edrivers/rapidio/rio-driver.c
@@ -116,23 +116,23 @@
116 subsystem. 116 subsystem.
117 </para> 117 </para>
118 118
119 <sect1><title>Structures</title> 119 <sect1 id="Structures"><title>Structures</title>
120!Iinclude/linux/rio.h 120!Iinclude/linux/rio.h
121 </sect1> 121 </sect1>
122 <sect1><title>Enumeration and Discovery</title> 122 <sect1 id="Enumeration_and_Discovery"><title>Enumeration and Discovery</title>
123!Idrivers/rapidio/rio-scan.c 123!Idrivers/rapidio/rio-scan.c
124 </sect1> 124 </sect1>
125 <sect1><title>Driver functionality</title> 125 <sect1 id="Driver_functionality"><title>Driver functionality</title>
126!Idrivers/rapidio/rio.c 126!Idrivers/rapidio/rio.c
127!Idrivers/rapidio/rio-access.c 127!Idrivers/rapidio/rio-access.c
128 </sect1> 128 </sect1>
129 <sect1><title>Device model support</title> 129 <sect1 id="Device_model_support"><title>Device model support</title>
130!Idrivers/rapidio/rio-driver.c 130!Idrivers/rapidio/rio-driver.c
131 </sect1> 131 </sect1>
132 <sect1><title>Sysfs support</title> 132 <sect1 id="Sysfs_support"><title>Sysfs support</title>
133!Idrivers/rapidio/rio-sysfs.c 133!Idrivers/rapidio/rio-sysfs.c
134 </sect1> 134 </sect1>
135 <sect1><title>PPC32 support</title> 135 <sect1 id="PPC32_support"><title>PPC32 support</title>
136!Iarch/powerpc/kernel/rio.c 136!Iarch/powerpc/kernel/rio.c
137!Earch/powerpc/sysdev/fsl_rio.c 137!Earch/powerpc/sysdev/fsl_rio.c
138!Iarch/powerpc/sysdev/fsl_rio.c 138!Iarch/powerpc/sysdev/fsl_rio.c
diff --git a/Documentation/DocBook/videobook.tmpl b/Documentation/DocBook/videobook.tmpl
index b3d93ee27693..89817795e668 100644
--- a/Documentation/DocBook/videobook.tmpl
+++ b/Documentation/DocBook/videobook.tmpl
@@ -170,7 +170,7 @@ int __init myradio_init(struct video_init *v)
170 <para> 170 <para>
171 The types available are 171 The types available are
172 </para> 172 </para>
173 <table frame="all"><title>Device Types</title> 173 <table frame="all" id="Device_Types"><title>Device Types</title>
174 <tgroup cols="3" align="left"> 174 <tgroup cols="3" align="left">
175 <tbody> 175 <tbody>
176 <row> 176 <row>
@@ -291,7 +291,7 @@ static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
291 allows the applications to find out what sort of a card they have found and 291 allows the applications to find out what sort of a card they have found and
292 to figure out what they want to do about it. The fields in the structure are 292 to figure out what they want to do about it. The fields in the structure are
293 </para> 293 </para>
294 <table frame="all"><title>struct video_capability fields</title> 294 <table frame="all" id="video_capability_fields"><title>struct video_capability fields</title>
295 <tgroup cols="2" align="left"> 295 <tgroup cols="2" align="left">
296 <tbody> 296 <tbody>
297 <row> 297 <row>
@@ -365,7 +365,7 @@ static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
365 <para> 365 <para>
366 The video_tuner structure has the following fields 366 The video_tuner structure has the following fields
367 </para> 367 </para>
368 <table frame="all"><title>struct video_tuner fields</title> 368 <table frame="all" id="video_tuner_fields"><title>struct video_tuner fields</title>
369 <tgroup cols="2" align="left"> 369 <tgroup cols="2" align="left">
370 <tbody> 370 <tbody>
371 <row> 371 <row>
@@ -398,7 +398,7 @@ static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
398 </tgroup> 398 </tgroup>
399 </table> 399 </table>
400 400
401 <table frame="all"><title>struct video_tuner flags</title> 401 <table frame="all" id="video_tuner_flags"><title>struct video_tuner flags</title>
402 <tgroup cols="2" align="left"> 402 <tgroup cols="2" align="left">
403 <tbody> 403 <tbody>
404 <row> 404 <row>
@@ -421,7 +421,7 @@ static int radio_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
421 </tgroup> 421 </tgroup>
422 </table> 422 </table>
423 423
424 <table frame="all"><title>struct video_tuner modes</title> 424 <table frame="all" id="video_tuner_modes"><title>struct video_tuner modes</title>
425 <tgroup cols="2" align="left"> 425 <tgroup cols="2" align="left">
426 <tbody> 426 <tbody>
427 <row> 427 <row>
@@ -572,7 +572,7 @@ static int current_volume=0;
572 <para> 572 <para>
573 Then we fill in the video_audio structure. This has the following format 573 Then we fill in the video_audio structure. This has the following format
574 </para> 574 </para>
575 <table frame="all"><title>struct video_audio fields</title> 575 <table frame="all" id="video_audio_fields"><title>struct video_audio fields</title>
576 <tgroup cols="2" align="left"> 576 <tgroup cols="2" align="left">
577 <tbody> 577 <tbody>
578 <row> 578 <row>
@@ -607,7 +607,7 @@ static int current_volume=0;
607 </tgroup> 607 </tgroup>
608 </table> 608 </table>
609 609
610 <table frame="all"><title>struct video_audio flags</title> 610 <table frame="all" id="video_audio_flags"><title>struct video_audio flags</title>
611 <tgroup cols="2" align="left"> 611 <tgroup cols="2" align="left">
612 <tbody> 612 <tbody>
613 <row> 613 <row>
@@ -625,7 +625,7 @@ static int current_volume=0;
625 </tgroup> 625 </tgroup>
626 </table> 626 </table>
627 627
628 <table frame="all"><title>struct video_audio modes</title> 628 <table frame="all" id="video_audio_modes"><title>struct video_audio modes</title>
629 <tgroup cols="2" align="left"> 629 <tgroup cols="2" align="left">
630 <tbody> 630 <tbody>
631 <row> 631 <row>
@@ -775,7 +775,7 @@ module_exit(cleanup);
775 </para> 775 </para>
776 </sect1> 776 </sect1>
777 </chapter> 777 </chapter>
778 <chapter> 778 <chapter id="Video_Capture_Devices">
779 <title>Video Capture Devices</title> 779 <title>Video Capture Devices</title>
780 <sect1 id="introvid"> 780 <sect1 id="introvid">
781 <title>Video Capture Device Types</title> 781 <title>Video Capture Device Types</title>
@@ -855,7 +855,7 @@ static struct video_device my_camera
855 We use the extra video capability flags that did not apply to the 855 We use the extra video capability flags that did not apply to the
856 radio interface. The video related flags are 856 radio interface. The video related flags are
857 </para> 857 </para>
858 <table frame="all"><title>Capture Capabilities</title> 858 <table frame="all" id="Capture_Capabilities"><title>Capture Capabilities</title>
859 <tgroup cols="2" align="left"> 859 <tgroup cols="2" align="left">
860 <tbody> 860 <tbody>
861 <row> 861 <row>
@@ -1195,7 +1195,7 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
1195 inputs to the video card). Our example card has a single camera input. The 1195 inputs to the video card). Our example card has a single camera input. The
1196 fields in the structure are 1196 fields in the structure are
1197 </para> 1197 </para>
1198 <table frame="all"><title>struct video_channel fields</title> 1198 <table frame="all" id="video_channel_fields"><title>struct video_channel fields</title>
1199 <tgroup cols="2" align="left"> 1199 <tgroup cols="2" align="left">
1200 <tbody> 1200 <tbody>
1201 <row> 1201 <row>
@@ -1218,7 +1218,7 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
1218 </tbody> 1218 </tbody>
1219 </tgroup> 1219 </tgroup>
1220 </table> 1220 </table>
1221 <table frame="all"><title>struct video_channel flags</title> 1221 <table frame="all" id="video_channel_flags"><title>struct video_channel flags</title>
1222 <tgroup cols="2" align="left"> 1222 <tgroup cols="2" align="left">
1223 <tbody> 1223 <tbody>
1224 <row> 1224 <row>
@@ -1229,7 +1229,7 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
1229 </tbody> 1229 </tbody>
1230 </tgroup> 1230 </tgroup>
1231 </table> 1231 </table>
1232 <table frame="all"><title>struct video_channel types</title> 1232 <table frame="all" id="video_channel_types"><title>struct video_channel types</title>
1233 <tgroup cols="2" align="left"> 1233 <tgroup cols="2" align="left">
1234 <tbody> 1234 <tbody>
1235 <row> 1235 <row>
@@ -1242,7 +1242,7 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
1242 </tbody> 1242 </tbody>
1243 </tgroup> 1243 </tgroup>
1244 </table> 1244 </table>
1245 <table frame="all"><title>struct video_channel norms</title> 1245 <table frame="all" id="video_channel_norms"><title>struct video_channel norms</title>
1246 <tgroup cols="2" align="left"> 1246 <tgroup cols="2" align="left">
1247 <tbody> 1247 <tbody>
1248 <row> 1248 <row>
@@ -1328,7 +1328,7 @@ static int camera_ioctl(struct video_device *dev, unsigned int cmd, void *arg)
1328 for every other pixel in the image. The other common formats the interface 1328 for every other pixel in the image. The other common formats the interface
1329 defines are 1329 defines are
1330 </para> 1330 </para>
1331 <table frame="all"><title>Framebuffer Encodings</title> 1331 <table frame="all" id="Framebuffer_Encodings"><title>Framebuffer Encodings</title>
1332 <tgroup cols="2" align="left"> 1332 <tgroup cols="2" align="left">
1333 <tbody> 1333 <tbody>
1334 <row> 1334 <row>
@@ -1466,7 +1466,7 @@ static struct video_buffer capture_fb;
1466 display. The video_window structure is used to describe the way the image 1466 display. The video_window structure is used to describe the way the image
1467 should be displayed. 1467 should be displayed.
1468 </para> 1468 </para>
1469 <table frame="all"><title>struct video_window fields</title> 1469 <table frame="all" id="video_window_fields"><title>struct video_window fields</title>
1470 <tgroup cols="2" align="left"> 1470 <tgroup cols="2" align="left">
1471 <tbody> 1471 <tbody>
1472 <row> 1472 <row>
@@ -1503,7 +1503,7 @@ static struct video_buffer capture_fb;
1503 <para> 1503 <para>
1504 Each clip is a struct video_clip which has the following fields 1504 Each clip is a struct video_clip which has the following fields
1505 </para> 1505 </para>
1506 <table frame="all"><title>video_clip fields</title> 1506 <table frame="all" id="video_clip_fields"><title>video_clip fields</title>
1507 <tgroup cols="2" align="left"> 1507 <tgroup cols="2" align="left">
1508 <tbody> 1508 <tbody>
1509 <row> 1509 <row>
diff --git a/Documentation/DocBook/z8530book.tmpl b/Documentation/DocBook/z8530book.tmpl
index a507876447aa..42c75ba71ba2 100644
--- a/Documentation/DocBook/z8530book.tmpl
+++ b/Documentation/DocBook/z8530book.tmpl
@@ -77,7 +77,7 @@
77 </para> 77 </para>
78 </chapter> 78 </chapter>
79 79
80 <chapter> 80 <chapter id="Driver_Modes">
81 <title>Driver Modes</title> 81 <title>Driver Modes</title>
82 <para> 82 <para>
83 The Z85230 driver layer can drive Z8530, Z85C30 and Z85230 devices 83 The Z85230 driver layer can drive Z8530, Z85C30 and Z85230 devices
@@ -108,7 +108,7 @@
108 </para> 108 </para>
109 </chapter> 109 </chapter>
110 110
111 <chapter> 111 <chapter id="Using_the_Z85230_driver">
112 <title>Using the Z85230 driver</title> 112 <title>Using the Z85230 driver</title>
113 <para> 113 <para>
114 The Z85230 driver provides the back end interface to your board. To 114 The Z85230 driver provides the back end interface to your board. To
@@ -174,7 +174,7 @@
174 </para> 174 </para>
175 </chapter> 175 </chapter>
176 176
177 <chapter> 177 <chapter id="Attaching_Network_Interfaces">
178 <title>Attaching Network Interfaces</title> 178 <title>Attaching Network Interfaces</title>
179 <para> 179 <para>
180 If you wish to use the network interface facilities of the driver, 180 If you wish to use the network interface facilities of the driver,
@@ -216,7 +216,7 @@
216 </para> 216 </para>
217 </chapter> 217 </chapter>
218 218
219 <chapter> 219 <chapter id="Configuring_And_Activating_The_Port">
220 <title>Configuring And Activating The Port</title> 220 <title>Configuring And Activating The Port</title>
221 <para> 221 <para>
222 The Z85230 driver provides helper functions and tables to load the 222 The Z85230 driver provides helper functions and tables to load the
@@ -300,7 +300,7 @@
300 </para> 300 </para>
301 </chapter> 301 </chapter>
302 302
303 <chapter> 303 <chapter id="Network_Layer_Functions">
304 <title>Network Layer Functions</title> 304 <title>Network Layer Functions</title>
305 <para> 305 <para>
306 The Z8530 layer provides functions to queue packets for 306 The Z8530 layer provides functions to queue packets for
@@ -327,7 +327,7 @@
327 </para> 327 </para>
328 </chapter> 328 </chapter>
329 329
330 <chapter> 330 <chapter id="Porting_The_Z8530_Driver">
331 <title>Porting The Z8530 Driver</title> 331 <title>Porting The Z8530 Driver</title>
332 <para> 332 <para>
333 The Z8530 driver is written to be portable. In DMA mode it makes 333 The Z8530 driver is written to be portable. In DMA mode it makes
diff --git a/Documentation/cgroups.txt b/Documentation/cgroups.txt
index 98a26f81fa75..42d7c4cb39cd 100644
--- a/Documentation/cgroups.txt
+++ b/Documentation/cgroups.txt
@@ -456,7 +456,7 @@ methods are create/destroy. Any others that are null are presumed to
456be successful no-ops. 456be successful no-ops.
457 457
458struct cgroup_subsys_state *create(struct cgroup *cont) 458struct cgroup_subsys_state *create(struct cgroup *cont)
459LL=cgroup_mutex 459(cgroup_mutex held by caller)
460 460
461Called to create a subsystem state object for a cgroup. The 461Called to create a subsystem state object for a cgroup. The
462subsystem should allocate its subsystem state object for the passed 462subsystem should allocate its subsystem state object for the passed
@@ -471,14 +471,19 @@ it's the root of the hierarchy) and may be an appropriate place for
471initialization code. 471initialization code.
472 472
473void destroy(struct cgroup *cont) 473void destroy(struct cgroup *cont)
474LL=cgroup_mutex 474(cgroup_mutex held by caller)
475 475
476The cgroup system is about to destroy the passed cgroup; the 476The cgroup system is about to destroy the passed cgroup; the subsystem
477subsystem should do any necessary cleanup 477should do any necessary cleanup and free its subsystem state
478object. By the time this method is called, the cgroup has already been
479unlinked from the file system and from the child list of its parent;
480cgroup->parent is still valid. (Note - can also be called for a
481newly-created cgroup if an error occurs after this subsystem's
482create() method has been called for the new cgroup).
478 483
479int can_attach(struct cgroup_subsys *ss, struct cgroup *cont, 484int can_attach(struct cgroup_subsys *ss, struct cgroup *cont,
480 struct task_struct *task) 485 struct task_struct *task)
481LL=cgroup_mutex 486(cgroup_mutex held by caller)
482 487
483Called prior to moving a task into a cgroup; if the subsystem 488Called prior to moving a task into a cgroup; if the subsystem
484returns an error, this will abort the attach operation. If a NULL 489returns an error, this will abort the attach operation. If a NULL
@@ -489,25 +494,20 @@ remain valid while the caller holds cgroup_mutex.
489 494
490void attach(struct cgroup_subsys *ss, struct cgroup *cont, 495void attach(struct cgroup_subsys *ss, struct cgroup *cont,
491 struct cgroup *old_cont, struct task_struct *task) 496 struct cgroup *old_cont, struct task_struct *task)
492LL=cgroup_mutex
493
494 497
495Called after the task has been attached to the cgroup, to allow any 498Called after the task has been attached to the cgroup, to allow any
496post-attachment activity that requires memory allocations or blocking. 499post-attachment activity that requires memory allocations or blocking.
497 500
498void fork(struct cgroup_subsy *ss, struct task_struct *task) 501void fork(struct cgroup_subsy *ss, struct task_struct *task)
499LL=callback_mutex, maybe read_lock(tasklist_lock)
500 502
501Called when a task is forked into a cgroup. Also called during 503Called when a task is forked into a cgroup. Also called during
502registration for all existing tasks. 504registration for all existing tasks.
503 505
504void exit(struct cgroup_subsys *ss, struct task_struct *task) 506void exit(struct cgroup_subsys *ss, struct task_struct *task)
505LL=callback_mutex
506 507
507Called during task exit 508Called during task exit
508 509
509int populate(struct cgroup_subsys *ss, struct cgroup *cont) 510int populate(struct cgroup_subsys *ss, struct cgroup *cont)
510LL=none
511 511
512Called after creation of a cgroup to allow a subsystem to populate 512Called after creation of a cgroup to allow a subsystem to populate
513the cgroup directory with file entries. The subsystem should make 513the cgroup directory with file entries. The subsystem should make
@@ -524,7 +524,7 @@ example in cpusets, no task may attach before 'cpus' and 'mems' are set
524up. 524up.
525 525
526void bind(struct cgroup_subsys *ss, struct cgroup *root) 526void bind(struct cgroup_subsys *ss, struct cgroup *root)
527LL=callback_mutex 527(cgroup_mutex held by caller)
528 528
529Called when a cgroup subsystem is rebound to a different hierarchy 529Called when a cgroup subsystem is rebound to a different hierarchy
530and root cgroup. Currently this will only involve movement between 530and root cgroup. Currently this will only involve movement between
diff --git a/Documentation/controllers/memory.txt b/Documentation/controllers/memory.txt
new file mode 100644
index 000000000000..b5bbea92a61a
--- /dev/null
+++ b/Documentation/controllers/memory.txt
@@ -0,0 +1,279 @@
1Memory Controller
2
3Salient features
4
5a. Enable control of both RSS (mapped) and Page Cache (unmapped) pages
6b. The infrastructure allows easy addition of other types of memory to control
7c. Provides *zero overhead* for non memory controller users
8d. Provides a double LRU: global memory pressure causes reclaim from the
9 global LRU; a cgroup on hitting a limit, reclaims from the per
10 cgroup LRU
11
12NOTE: Swap Cache (unmapped) is not accounted now.
13
14Benefits and Purpose of the memory controller
15
16The memory controller isolates the memory behaviour of a group of tasks
17from the rest of the system. The article on LWN [12] mentions some probable
18uses of the memory controller. The memory controller can be used to
19
20a. Isolate an application or a group of applications
21 Memory hungry applications can be isolated and limited to a smaller
22 amount of memory.
23b. Create a cgroup with limited amount of memory, this can be used
24 as a good alternative to booting with mem=XXXX.
25c. Virtualization solutions can control the amount of memory they want
26 to assign to a virtual machine instance.
27d. A CD/DVD burner could control the amount of memory used by the
28 rest of the system to ensure that burning does not fail due to lack
29 of available memory.
30e. There are several other use cases, find one or use the controller just
31 for fun (to learn and hack on the VM subsystem).
32
331. History
34
35The memory controller has a long history. A request for comments for the memory
36controller was posted by Balbir Singh [1]. At the time the RFC was posted
37there were several implementations for memory control. The goal of the
38RFC was to build consensus and agreement for the minimal features required
39for memory control. The first RSS controller was posted by Balbir Singh[2]
40in Feb 2007. Pavel Emelianov [3][4][5] has since posted three versions of the
41RSS controller. At OLS, at the resource management BoF, everyone suggested
42that we handle both page cache and RSS together. Another request was raised
43to allow user space handling of OOM. The current memory controller is
44at version 6; it combines both mapped (RSS) and unmapped Page
45Cache Control [11].
46
472. Memory Control
48
49Memory is a unique resource in the sense that it is present in a limited
50amount. If a task requires a lot of CPU processing, the task can spread
51its processing over a period of hours, days, months or years, but with
52memory, the same physical memory needs to be reused to accomplish the task.
53
54The memory controller implementation has been divided into phases. These
55are:
56
571. Memory controller
582. mlock(2) controller
593. Kernel user memory accounting and slab control
604. user mappings length controller
61
62The memory controller is the first controller developed.
63
642.1. Design
65
66The core of the design is a counter called the res_counter. The res_counter
67tracks the current memory usage and limit of the group of processes associated
68with the controller. Each cgroup has a memory controller specific data
69structure (mem_cgroup) associated with it.
70
712.2. Accounting
72
73 +--------------------+
74 | mem_cgroup |
75 | (res_counter) |
76 +--------------------+
77 / ^ \
78 / | \
79 +---------------+ | +---------------+
80 | mm_struct | |.... | mm_struct |
81 | | | | |
82 +---------------+ | +---------------+
83 |
84 + --------------+
85 |
86 +---------------+ +------+--------+
87 | page +----------> page_cgroup|
88 | | | |
89 +---------------+ +---------------+
90
91 (Figure 1: Hierarchy of Accounting)
92
93
94Figure 1 shows the important aspects of the controller
95
961. Accounting happens per cgroup
972. Each mm_struct knows about which cgroup it belongs to
983. Each page has a pointer to the page_cgroup, which in turn knows the
99 cgroup it belongs to
100
101The accounting is done as follows: mem_cgroup_charge() is invoked to setup
102the necessary data structures and check if the cgroup that is being charged
103is over its limit. If it is then reclaim is invoked on the cgroup.
104More details can be found in the reclaim section of this document.
105If everything goes well, a page meta-data-structure called page_cgroup is
106allocated and associated with the page. This routine also adds the page to
107the per cgroup LRU.
108
1092.2.1 Accounting details
110
111All mapped pages (RSS) and unmapped user pages (Page Cache) are accounted.
112RSS pages are accounted at the time of page_add_*_rmap() unless they've already
113been accounted for earlier. A file page will be accounted for as Page Cache;
114it's mapped into the page tables of a process, duplicate accounting is carefully
115avoided. Page Cache pages are accounted at the time of add_to_page_cache().
116The corresponding routines that remove a page from the page tables or removes
117a page from Page Cache is used to decrement the accounting counters of the
118cgroup.
119
1202.3 Shared Page Accounting
121
122Shared pages are accounted on the basis of the first touch approach. The
123cgroup that first touches a page is accounted for the page. The principle
124behind this approach is that a cgroup that aggressively uses a shared
125page will eventually get charged for it (once it is uncharged from
126the cgroup that brought it in -- this will happen on memory pressure).
127
1282.4 Reclaim
129
130Each cgroup maintains a per cgroup LRU that consists of an active
131and inactive list. When a cgroup goes over its limit, we first try
132to reclaim memory from the cgroup so as to make space for the new
133pages that the cgroup has touched. If the reclaim is unsuccessful,
134an OOM routine is invoked to select and kill the bulkiest task in the
135cgroup.
136
137The reclaim algorithm has not been modified for cgroups, except that
138pages that are selected for reclaiming come from the per cgroup LRU
139list.
140
1412. Locking
142
143The memory controller uses the following hierarchy
144
1451. zone->lru_lock is used for selecting pages to be isolated
1462. mem->per_zone->lru_lock protects the per cgroup LRU (per zone)
1473. lock_page_cgroup() is used to protect page->page_cgroup
148
1493. User Interface
150
1510. Configuration
152
153a. Enable CONFIG_CGROUPS
154b. Enable CONFIG_RESOURCE_COUNTERS
155c. Enable CONFIG_CGROUP_MEM_CONT
156
1571. Prepare the cgroups
158# mkdir -p /cgroups
159# mount -t cgroup none /cgroups -o memory
160
1612. Make the new group and move bash into it
162# mkdir /cgroups/0
163# echo $$ > /cgroups/0/tasks
164
165Since now we're in the 0 cgroup,
166We can alter the memory limit:
167# echo -n 4M > /cgroups/0/memory.limit_in_bytes
168
169NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo,
170mega or gigabytes.
171
172# cat /cgroups/0/memory.limit_in_bytes
1734194304 Bytes
174
175NOTE: The interface has now changed to display the usage in bytes
176instead of pages
177
178We can check the usage:
179# cat /cgroups/0/memory.usage_in_bytes
1801216512 Bytes
181
182A successful write to this file does not guarantee a successful set of
183this limit to the value written into the file. This can be due to a
184number of factors, such as rounding up to page boundaries or the total
185availability of memory on the system. The user is required to re-read
186this file after a write to guarantee the value committed by the kernel.
187
188# echo -n 1 > memory.limit_in_bytes
189# cat memory.limit_in_bytes
1904096 Bytes
191
192The memory.failcnt field gives the number of times that the cgroup limit was
193exceeded.
194
195The memory.stat file gives accounting information. Now, the number of
196caches, RSS and Active pages/Inactive pages are shown.
197
198The memory.force_empty gives an interface to drop *all* charges by force.
199
200# echo -n 1 > memory.force_empty
201
202will drop all charges in cgroup. Currently, this is maintained for test.
203
2044. Testing
205
206Balbir posted lmbench, AIM9, LTP and vmmstress results [10] and [11].
207Apart from that v6 has been tested with several applications and regular
208daily use. The controller has also been tested on the PPC64, x86_64 and
209UML platforms.
210
2114.1 Troubleshooting
212
213Sometimes a user might find that the application under a cgroup is
214terminated. There are several causes for this:
215
2161. The cgroup limit is too low (just too low to do anything useful)
2172. The user is using anonymous memory and swap is turned off or too low
218
219A sync followed by echo 1 > /proc/sys/vm/drop_caches will help get rid of
220some of the pages cached in the cgroup (page cache pages).
221
2224.2 Task migration
223
224When a task migrates from one cgroup to another, it's charge is not
225carried forward. The pages allocated from the original cgroup still
226remain charged to it, the charge is dropped when the page is freed or
227reclaimed.
228
2294.3 Removing a cgroup
230
231A cgroup can be removed by rmdir, but as discussed in sections 4.1 and 4.2, a
232cgroup might have some charge associated with it, even though all
233tasks have migrated away from it. Such charges are automatically dropped at
234rmdir() if there are no tasks.
235
2364.4 Choosing what to account -- Page Cache (unmapped) vs RSS (mapped)?
237
238The type of memory accounted by the cgroup can be limited to just
239mapped pages by writing "1" to memory.control_type field
240
241echo -n 1 > memory.control_type
242
2435. TODO
244
2451. Add support for accounting huge pages (as a separate controller)
2462. Make per-cgroup scanner reclaim not-shared pages first
2473. Teach controller to account for shared-pages
2484. Start reclamation when the limit is lowered
2495. Start reclamation in the background when the limit is
250 not yet hit but the usage is getting closer
251
252Summary
253
254Overall, the memory controller has been a stable controller and has been
255commented and discussed quite extensively in the community.
256
257References
258
2591. Singh, Balbir. RFC: Memory Controller, http://lwn.net/Articles/206697/
2602. Singh, Balbir. Memory Controller (RSS Control),
261 http://lwn.net/Articles/222762/
2623. Emelianov, Pavel. Resource controllers based on process cgroups
263 http://lkml.org/lkml/2007/3/6/198
2644. Emelianov, Pavel. RSS controller based on process cgroups (v2)
265 http://lkml.org/lkml/2007/4/9/74
2665. Emelianov, Pavel. RSS controller based on process cgroups (v3)
267 http://lkml.org/lkml/2007/5/30/244
2686. Menage, Paul. Control Groups v10, http://lwn.net/Articles/236032/
2697. Vaidyanathan, Srinivasan, Control Groups: Pagecache accounting and control
270 subsystem (v3), http://lwn.net/Articles/235534/
2718. Singh, Balbir. RSS controller V2 test results (lmbench),
272 http://lkml.org/lkml/2007/5/17/232
2739. Singh, Balbir. RSS controller V2 AIM9 results
274 http://lkml.org/lkml/2007/5/18/1
27510. Singh, Balbir. Memory controller v6 results,
276 http://lkml.org/lkml/2007/8/19/36
27711. Singh, Balbir. Memory controller v6, http://lkml.org/lkml/2007/8/17/69
27812. Corbet, Jonathan, Controlling memory use in cgroups,
279 http://lwn.net/Articles/243795/
diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt
index 141bef1c8599..43db6fe12814 100644
--- a/Documentation/cpusets.txt
+++ b/Documentation/cpusets.txt
@@ -523,21 +523,14 @@ from one cpuset to another, then the kernel will adjust the tasks
523memory placement, as above, the next time that the kernel attempts 523memory placement, as above, the next time that the kernel attempts
524to allocate a page of memory for that task. 524to allocate a page of memory for that task.
525 525
526If a cpuset has its CPUs modified, then each task using that 526If a cpuset has its 'cpus' modified, then each task in that cpuset
527cpuset does _not_ change its behavior automatically. In order to 527will have its allowed CPU placement changed immediately. Similarly,
528minimize the impact on the critical scheduling code in the kernel, 528if a tasks pid is written to a cpusets 'tasks' file, in either its
529tasks will continue to use their prior CPU placement until they 529current cpuset or another cpuset, then its allowed CPU placement is
530are rebound to their cpuset, by rewriting their pid to the 'tasks' 530changed immediately. If such a task had been bound to some subset
531file of their cpuset. If a task had been bound to some subset of its 531of its cpuset using the sched_setaffinity() call, the task will be
532cpuset using the sched_setaffinity() call, and if any of that subset 532allowed to run on any CPU allowed in its new cpuset, negating the
533is still allowed in its new cpuset settings, then the task will be 533affect of the prior sched_setaffinity() call.
534restricted to the intersection of the CPUs it was allowed on before,
535and its new cpuset CPU placement. If, on the other hand, there is
536no overlap between a tasks prior placement and its new cpuset CPU
537placement, then the task will be allowed to run on any CPU allowed
538in its new cpuset. If a task is moved from one cpuset to another,
539its CPU placement is updated in the same way as if the tasks pid is
540rewritten to the 'tasks' file of its current cpuset.
541 534
542In summary, the memory placement of a task whose cpuset is changed is 535In summary, the memory placement of a task whose cpuset is changed is
543updated by the kernel, on the next allocation of a page for that task, 536updated by the kernel, on the next allocation of a page for that task,
diff --git a/Documentation/drivers/edac/edac.txt b/Documentation/edac.txt
index a5c36842ecef..a5c36842ecef 100644
--- a/Documentation/drivers/edac/edac.txt
+++ b/Documentation/edac.txt
diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt
index 113165b48305..2ebb94d6ed8e 100644
--- a/Documentation/email-clients.txt
+++ b/Documentation/email-clients.txt
@@ -170,7 +170,6 @@ Sylpheed (GUI)
170 170
171- Works well for inlining text (or using attachments). 171- Works well for inlining text (or using attachments).
172- Allows use of an external editor. 172- Allows use of an external editor.
173- Not good for IMAP.
174- Is slow on large folders. 173- Is slow on large folders.
175- Won't do TLS SMTP auth over a non-SSL connection. 174- Won't do TLS SMTP auth over a non-SSL connection.
176- Has a helpful ruler bar in the compose window. 175- Has a helpful ruler bar in the compose window.
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 68ce1300a360..17b1659bd3f8 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -6,14 +6,6 @@ be removed from this file.
6 6
7--------------------------- 7---------------------------
8 8
9What: MXSER
10When: December 2007
11Why: Old mxser driver is obsoleted by the mxser_new. Give it some time yet
12 and remove it.
13Who: Jiri Slaby <jirislaby@gmail.com>
14
15---------------------------
16
17What: dev->power.power_state 9What: dev->power.power_state
18When: July 2007 10When: July 2007
19Why: Broken design for runtime control over driver power states, confusing 11Why: Broken design for runtime control over driver power states, confusing
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX
index 1de155e2dc36..e68021c08fbd 100644
--- a/Documentation/filesystems/00-INDEX
+++ b/Documentation/filesystems/00-INDEX
@@ -32,6 +32,8 @@ directory-locking
32 - info about the locking scheme used for directory operations. 32 - info about the locking scheme used for directory operations.
33dlmfs.txt 33dlmfs.txt
34 - info on the userspace interface to the OCFS2 DLM. 34 - info on the userspace interface to the OCFS2 DLM.
35dnotify.txt
36 - info about directory notification in Linux.
35ecryptfs.txt 37ecryptfs.txt
36 - docs on eCryptfs: stacked cryptographic filesystem for Linux. 38 - docs on eCryptfs: stacked cryptographic filesystem for Linux.
37ext2.txt 39ext2.txt
@@ -80,6 +82,8 @@ relay.txt
80 - info on relay, for efficient streaming from kernel to user space. 82 - info on relay, for efficient streaming from kernel to user space.
81romfs.txt 83romfs.txt
82 - description of the ROMFS filesystem. 84 - description of the ROMFS filesystem.
85sharedsubtree.txt
86 - a description of shared subtrees for namespaces.
83smbfs.txt 87smbfs.txt
84 - info on using filesystems with the SMB protocol (Win 3.11 and NT). 88 - info on using filesystems with the SMB protocol (Win 3.11 and NT).
85spufs.txt 89spufs.txt
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 37c10cba7177..42d4b30b1045 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -90,7 +90,6 @@ of the locking scheme for directory operations.
90prototypes: 90prototypes:
91 struct inode *(*alloc_inode)(struct super_block *sb); 91 struct inode *(*alloc_inode)(struct super_block *sb);
92 void (*destroy_inode)(struct inode *); 92 void (*destroy_inode)(struct inode *);
93 void (*read_inode) (struct inode *);
94 void (*dirty_inode) (struct inode *); 93 void (*dirty_inode) (struct inode *);
95 int (*write_inode) (struct inode *, int); 94 int (*write_inode) (struct inode *, int);
96 void (*put_inode) (struct inode *); 95 void (*put_inode) (struct inode *);
@@ -114,7 +113,6 @@ locking rules:
114 BKL s_lock s_umount 113 BKL s_lock s_umount
115alloc_inode: no no no 114alloc_inode: no no no
116destroy_inode: no 115destroy_inode: no
117read_inode: no (see below)
118dirty_inode: no (must not sleep) 116dirty_inode: no (must not sleep)
119write_inode: no 117write_inode: no
120put_inode: no 118put_inode: no
@@ -133,7 +131,6 @@ show_options: no (vfsmount->sem)
133quota_read: no no no (see below) 131quota_read: no no no (see below)
134quota_write: no no no (see below) 132quota_write: no no no (see below)
135 133
136->read_inode() is not a method - it's a callback used in iget().
137->remount_fs() will have the s_umount lock if it's already mounted. 134->remount_fs() will have the s_umount lock if it's already mounted.
138When called from get_sb_single, it does NOT have the s_umount lock. 135When called from get_sb_single, it does NOT have the s_umount lock.
139->quota_read() and ->quota_write() functions are both guaranteed to 136->quota_read() and ->quota_write() functions are both guaranteed to
diff --git a/Documentation/dnotify.txt b/Documentation/filesystems/dnotify.txt
index 6984fca6002a..9f5d338ddbb8 100644
--- a/Documentation/dnotify.txt
+++ b/Documentation/filesystems/dnotify.txt
@@ -69,24 +69,24 @@ Example
69 #include <signal.h> 69 #include <signal.h>
70 #include <stdio.h> 70 #include <stdio.h>
71 #include <unistd.h> 71 #include <unistd.h>
72 72
73 static volatile int event_fd; 73 static volatile int event_fd;
74 74
75 static void handler(int sig, siginfo_t *si, void *data) 75 static void handler(int sig, siginfo_t *si, void *data)
76 { 76 {
77 event_fd = si->si_fd; 77 event_fd = si->si_fd;
78 } 78 }
79 79
80 int main(void) 80 int main(void)
81 { 81 {
82 struct sigaction act; 82 struct sigaction act;
83 int fd; 83 int fd;
84 84
85 act.sa_sigaction = handler; 85 act.sa_sigaction = handler;
86 sigemptyset(&act.sa_mask); 86 sigemptyset(&act.sa_mask);
87 act.sa_flags = SA_SIGINFO; 87 act.sa_flags = SA_SIGINFO;
88 sigaction(SIGRTMIN + 1, &act, NULL); 88 sigaction(SIGRTMIN + 1, &act, NULL);
89 89
90 fd = open(".", O_RDONLY); 90 fd = open(".", O_RDONLY);
91 fcntl(fd, F_SETSIG, SIGRTMIN + 1); 91 fcntl(fd, F_SETSIG, SIGRTMIN + 1);
92 fcntl(fd, F_NOTIFY, DN_MODIFY|DN_CREATE|DN_MULTISHOT); 92 fcntl(fd, F_NOTIFY, DN_MODIFY|DN_CREATE|DN_MULTISHOT);
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting
index 0f33c77bc14b..92b888d540a6 100644
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@ -34,8 +34,8 @@ FOO_I(inode) (see in-tree filesystems for examples).
34 34
35Make them ->alloc_inode and ->destroy_inode in your super_operations. 35Make them ->alloc_inode and ->destroy_inode in your super_operations.
36 36
37Keep in mind that now you need explicit initialization of private data - 37Keep in mind that now you need explicit initialization of private data
38typically in ->read_inode() and after getting an inode from new_inode(). 38typically between calling iget_locked() and unlocking the inode.
39 39
40At some point that will become mandatory. 40At some point that will become mandatory.
41 41
@@ -173,10 +173,10 @@ should be a non-blocking function that initializes those parts of a
173newly created inode to allow the test function to succeed. 'data' is 173newly created inode to allow the test function to succeed. 'data' is
174passed as an opaque value to both test and set functions. 174passed as an opaque value to both test and set functions.
175 175
176When the inode has been created by iget5_locked(), it will be returned with 176When the inode has been created by iget5_locked(), it will be returned with the
177the I_NEW flag set and will still be locked. read_inode has not been 177I_NEW flag set and will still be locked. The filesystem then needs to finalize
178called so the file system still has to finalize the initialization. Once 178the initialization. Once the inode is initialized it must be unlocked by
179the inode is initialized it must be unlocked by calling unlock_new_inode(). 179calling unlock_new_inode().
180 180
181The filesystem is responsible for setting (and possibly testing) i_ino 181The filesystem is responsible for setting (and possibly testing) i_ino
182when appropriate. There is also a simpler iget_locked function that 182when appropriate. There is also a simpler iget_locked function that
@@ -184,11 +184,19 @@ just takes the superblock and inode number as arguments and does the
184test and set for you. 184test and set for you.
185 185
186e.g. 186e.g.
187 inode = iget_locked(sb, ino); 187 inode = iget_locked(sb, ino);
188 if (inode->i_state & I_NEW) { 188 if (inode->i_state & I_NEW) {
189 read_inode_from_disk(inode); 189 err = read_inode_from_disk(inode);
190 unlock_new_inode(inode); 190 if (err < 0) {
191 } 191 iget_failed(inode);
192 return err;
193 }
194 unlock_new_inode(inode);
195 }
196
197Note that if the process of setting up a new inode fails, then iget_failed()
198should be called on the inode to render it dead, and an appropriate error
199should be passed back to the caller.
192 200
193--- 201---
194[recommended] 202[recommended]
diff --git a/Documentation/sharedsubtree.txt b/Documentation/filesystems/sharedsubtree.txt
index 736540045dc7..736540045dc7 100644
--- a/Documentation/sharedsubtree.txt
+++ b/Documentation/filesystems/sharedsubtree.txt
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index 9d019d35728f..bd55038b56f5 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -203,8 +203,6 @@ struct super_operations {
203 struct inode *(*alloc_inode)(struct super_block *sb); 203 struct inode *(*alloc_inode)(struct super_block *sb);
204 void (*destroy_inode)(struct inode *); 204 void (*destroy_inode)(struct inode *);
205 205
206 void (*read_inode) (struct inode *);
207
208 void (*dirty_inode) (struct inode *); 206 void (*dirty_inode) (struct inode *);
209 int (*write_inode) (struct inode *, int); 207 int (*write_inode) (struct inode *, int);
210 void (*put_inode) (struct inode *); 208 void (*put_inode) (struct inode *);
@@ -242,15 +240,6 @@ or bottom half).
242 ->alloc_inode was defined and simply undoes anything done by 240 ->alloc_inode was defined and simply undoes anything done by
243 ->alloc_inode. 241 ->alloc_inode.
244 242
245 read_inode: this method is called to read a specific inode from the
246 mounted filesystem. The i_ino member in the struct inode is
247 initialized by the VFS to indicate which inode to read. Other
248 members are filled in by this method.
249
250 You can set this to NULL and use iget5_locked() instead of iget()
251 to read inodes. This is necessary for filesystems for which the
252 inode number is not sufficient to identify an inode.
253
254 dirty_inode: this method is called by the VFS to mark an inode dirty. 243 dirty_inode: this method is called by the VFS to mark an inode dirty.
255 244
256 write_inode: this method is called when the VFS needs to write an 245 write_inode: this method is called when the VFS needs to write an
@@ -308,9 +297,9 @@ or bottom half).
308 297
309 quota_write: called by the VFS to write to filesystem quota file. 298 quota_write: called by the VFS to write to filesystem quota file.
310 299
311The read_inode() method is responsible for filling in the "i_op" 300Whoever sets up the inode is responsible for filling in the "i_op" field. This
312field. This is a pointer to a "struct inode_operations" which 301is a pointer to a "struct inode_operations" which describes the methods that
313describes the methods that can be performed on individual inodes. 302can be performed on individual inodes.
314 303
315 304
316The Inode Object 305The Inode Object
diff --git a/Documentation/leds-class.txt b/Documentation/leds-class.txt
index 8c35c0426110..56757c751d6f 100644
--- a/Documentation/leds-class.txt
+++ b/Documentation/leds-class.txt
@@ -39,12 +39,33 @@ LED Device Naming
39 39
40Is currently of the form: 40Is currently of the form:
41 41
42"devicename:colour" 42"devicename:colour:function"
43 43
44There have been calls for LED properties such as colour to be exported as 44There have been calls for LED properties such as colour to be exported as
45individual led class attributes. As a solution which doesn't incur as much 45individual led class attributes. As a solution which doesn't incur as much
46overhead, I suggest these become part of the device name. The naming scheme 46overhead, I suggest these become part of the device name. The naming scheme
47above leaves scope for further attributes should they be needed. 47above leaves scope for further attributes should they be needed. If sections
48of the name don't apply, just leave that section blank.
49
50
51Hardware accelerated blink of LEDs
52==================================
53
54Some LEDs can be programmed to blink without any CPU interaction. To
55support this feature, a LED driver can optionally implement the
56blink_set() function (see <linux/leds.h>). If implemeted, triggers can
57attempt to use it before falling back to software timers. The blink_set()
58function should return 0 if the blink setting is supported, or -EINVAL
59otherwise, which means that LED blinking will be handled by software.
60
61The blink_set() function should choose a user friendly blinking
62value if it is called with *delay_on==0 && *delay_off==0 parameters. In
63this case the driver should give back the chosen value through delay_on
64and delay_off parameters to the leds subsystem.
65
66Any call to the brightness_set() callback function should cancel the
67previously programmed hardware blinking function so setting the brightness
68to 0 can also cancel the blinking of the LED.
48 69
49 70
50Known Issues 71Known Issues
@@ -55,10 +76,6 @@ would cause nightmare dependency issues. I see this as a minor issue
55compared to the benefits the simple trigger functionality brings. The 76compared to the benefits the simple trigger functionality brings. The
56rest of the LED subsystem can be modular. 77rest of the LED subsystem can be modular.
57 78
58Some leds can be programmed to flash in hardware. As this isn't a generic
59LED device property, this should be exported as a device specific sysfs
60attribute rather than part of the class if this functionality is required.
61
62 79
63Future Development 80Future Development
64================== 81==================
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index b5e46efeba84..7b4e8a70882c 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -57,6 +57,7 @@ Table of Contents
57 n) 4xx/Axon EMAC ethernet nodes 57 n) 4xx/Axon EMAC ethernet nodes
58 o) Xilinx IP cores 58 o) Xilinx IP cores
59 p) Freescale Synchronous Serial Interface 59 p) Freescale Synchronous Serial Interface
60 q) USB EHCI controllers
60 61
61 VII - Specifying interrupt information for devices 62 VII - Specifying interrupt information for devices
62 1) interrupts property 63 1) interrupts property
@@ -2577,6 +2578,20 @@ platforms are moved over to use the flattened-device-tree model.
2577 Requred properties: 2578 Requred properties:
2578 - current-speed : Baud rate of uartlite 2579 - current-speed : Baud rate of uartlite
2579 2580
2581 v) Xilinx hwicap
2582
2583 Xilinx hwicap devices provide access to the configuration logic
2584 of the FPGA through the Internal Configuration Access Port
2585 (ICAP). The ICAP enables partial reconfiguration of the FPGA,
2586 readback of the configuration information, and some control over
2587 'warm boots' of the FPGA fabric.
2588
2589 Required properties:
2590 - xlnx,family : The family of the FPGA, necessary since the
2591 capabilities of the underlying ICAP hardware
2592 differ between different families. May be
2593 'virtex2p', 'virtex4', or 'virtex5'.
2594
2580 p) Freescale Synchronous Serial Interface 2595 p) Freescale Synchronous Serial Interface
2581 2596
2582 The SSI is a serial device that communicates with audio codecs. It can 2597 The SSI is a serial device that communicates with audio codecs. It can
@@ -2775,6 +2790,33 @@ platforms are moved over to use the flattened-device-tree model.
2775 interrupt-parent = < &ipic >; 2790 interrupt-parent = < &ipic >;
2776 }; 2791 };
2777 2792
2793 q) USB EHCI controllers
2794
2795 Required properties:
2796 - compatible : should be "usb-ehci".
2797 - reg : should contain at least address and length of the standard EHCI
2798 register set for the device. Optional platform-dependent registers
2799 (debug-port or other) can be also specified here, but only after
2800 definition of standard EHCI registers.
2801 - interrupts : one EHCI interrupt should be described here.
2802 If device registers are implemented in big endian mode, the device
2803 node should have "big-endian-regs" property.
2804 If controller implementation operates with big endian descriptors,
2805 "big-endian-desc" property should be specified.
2806 If both big endian registers and descriptors are used by the controller
2807 implementation, "big-endian" property can be specified instead of having
2808 both "big-endian-regs" and "big-endian-desc".
2809
2810 Example (Sequoia 440EPx):
2811 ehci@e0000300 {
2812 compatible = "ibm,usb-ehci-440epx", "usb-ehci";
2813 interrupt-parent = <&UIC0>;
2814 interrupts = <1a 4>;
2815 reg = <0 e0000300 90 0 e0000390 70>;
2816 big-endian;
2817 };
2818
2819
2778 More devices will be defined as this spec matures. 2820 More devices will be defined as this spec matures.
2779 2821
2780VII - Specifying interrupt information for devices 2822VII - Specifying interrupt information for devices
diff --git a/Documentation/scheduler/00-INDEX b/Documentation/scheduler/00-INDEX
new file mode 100644
index 000000000000..b5f5ca069b2d
--- /dev/null
+++ b/Documentation/scheduler/00-INDEX
@@ -0,0 +1,16 @@
100-INDEX
2 - this file.
3sched-arch.txt
4 - CPU Scheduler implementation hints for architecture specific code.
5sched-coding.txt
6 - reference for various scheduler-related methods in the O(1) scheduler.
7sched-design.txt
8 - goals, design and implementation of the Linux O(1) scheduler.
9sched-design-CFS.txt
10 - goals, design and implementation of the Complete Fair Scheduler.
11sched-domains.txt
12 - information on scheduling domains.
13sched-nice-design.txt
14 - How and why the scheduler's nice levels are implemented.
15sched-stats.txt
16 - information on schedstats (Linux Scheduler Statistics).
diff --git a/Documentation/sched-arch.txt b/Documentation/scheduler/sched-arch.txt
index 941615a9769b..941615a9769b 100644
--- a/Documentation/sched-arch.txt
+++ b/Documentation/scheduler/sched-arch.txt
diff --git a/Documentation/sched-coding.txt b/Documentation/scheduler/sched-coding.txt
index cbd8db752acf..cbd8db752acf 100644
--- a/Documentation/sched-coding.txt
+++ b/Documentation/scheduler/sched-coding.txt
diff --git a/Documentation/sched-design-CFS.txt b/Documentation/scheduler/sched-design-CFS.txt
index 88bcb8767335..88bcb8767335 100644
--- a/Documentation/sched-design-CFS.txt
+++ b/Documentation/scheduler/sched-design-CFS.txt
diff --git a/Documentation/sched-design.txt b/Documentation/scheduler/sched-design.txt
index 1605bf0cba8b..1605bf0cba8b 100644
--- a/Documentation/sched-design.txt
+++ b/Documentation/scheduler/sched-design.txt
diff --git a/Documentation/sched-domains.txt b/Documentation/scheduler/sched-domains.txt
index a9e990ab980f..a9e990ab980f 100644
--- a/Documentation/sched-domains.txt
+++ b/Documentation/scheduler/sched-domains.txt
diff --git a/Documentation/sched-nice-design.txt b/Documentation/scheduler/sched-nice-design.txt
index e2bae5a577e3..e2bae5a577e3 100644
--- a/Documentation/sched-nice-design.txt
+++ b/Documentation/scheduler/sched-nice-design.txt
diff --git a/Documentation/sched-stats.txt b/Documentation/scheduler/sched-stats.txt
index 442e14d35dea..442e14d35dea 100644
--- a/Documentation/sched-stats.txt
+++ b/Documentation/scheduler/sched-stats.txt
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 24eac1bc735d..8a4863c4edd4 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -32,6 +32,7 @@ Currently, these files are in /proc/sys/vm:
32- min_unmapped_ratio 32- min_unmapped_ratio
33- min_slab_ratio 33- min_slab_ratio
34- panic_on_oom 34- panic_on_oom
35- oom_dump_tasks
35- oom_kill_allocating_task 36- oom_kill_allocating_task
36- mmap_min_address 37- mmap_min_address
37- numa_zonelist_order 38- numa_zonelist_order
@@ -232,6 +233,27 @@ according to your policy of failover.
232 233
233============================================================= 234=============================================================
234 235
236oom_dump_tasks
237
238Enables a system-wide task dump (excluding kernel threads) to be
239produced when the kernel performs an OOM-killing and includes such
240information as pid, uid, tgid, vm size, rss, cpu, oom_adj score, and
241name. This is helpful to determine why the OOM killer was invoked
242and to identify the rogue task that caused it.
243
244If this is set to zero, this information is suppressed. On very
245large systems with thousands of tasks it may not be feasible to dump
246the memory state information for each one. Such systems should not
247be forced to incur a performance penalty in OOM conditions when the
248information may not be desired.
249
250If this is set to non-zero, this information is shown whenever the
251OOM killer actually kills a memory-hogging task.
252
253The default value is 0.
254
255=============================================================
256
235oom_kill_allocating_task 257oom_kill_allocating_task
236 258
237This enables or disables killing the OOM-triggering task in 259This enables or disables killing the OOM-triggering task in
generated by cgit v1.2.2 (git 2.25.0) at 2025-02-09 01:46:04 -0500