diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/00-INDEX | 4 | ||||
-rw-r--r-- | Documentation/SubmittingPatches | 54 | ||||
-rw-r--r-- | Documentation/filesystems/00-INDEX | 6 | ||||
-rw-r--r-- | Documentation/filesystems/nfsroot.txt (renamed from Documentation/nfsroot.txt) | 0 | ||||
-rw-r--r-- | Documentation/filesystems/rpc-cache.txt (renamed from Documentation/rpc-cache.txt) | 0 | ||||
-rw-r--r-- | Documentation/filesystems/seq_file.txt | 283 | ||||
-rw-r--r-- | Documentation/hrtimers/highres.txt | 2 | ||||
-rw-r--r-- | Documentation/kernel-parameters.txt | 10 | ||||
-rw-r--r-- | Documentation/networking/can.txt | 8 | ||||
-rw-r--r-- | Documentation/scheduler/00-INDEX | 2 | ||||
-rw-r--r-- | Documentation/scheduler/sched-rt-group.txt (renamed from Documentation/sched-rt-group.txt) | 0 | ||||
-rw-r--r-- | Documentation/spi/spi-summary | 15 | ||||
-rw-r--r-- | Documentation/spinlocks.txt | 22 | ||||
-rw-r--r-- | Documentation/vm/hugetlbpage.txt | 7 |
14 files changed, 393 insertions, 20 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index fc8e7c7d182f..e8fb24671967 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX | |||
@@ -271,8 +271,6 @@ netlabel/ | |||
271 | - directory with information on the NetLabel subsystem. | 271 | - directory with information on the NetLabel subsystem. |
272 | networking/ | 272 | networking/ |
273 | - directory with info on various aspects of networking with Linux. | 273 | - directory with info on various aspects of networking with Linux. |
274 | nfsroot.txt | ||
275 | - short guide on setting up a diskless box with NFS root filesystem. | ||
276 | nmi_watchdog.txt | 274 | nmi_watchdog.txt |
277 | - info on NMI watchdog for SMP systems. | 275 | - info on NMI watchdog for SMP systems. |
278 | nommu-mmap.txt | 276 | nommu-mmap.txt |
@@ -321,8 +319,6 @@ robust-futexes.txt | |||
321 | - a description of what robust futexes are. | 319 | - a description of what robust futexes are. |
322 | rocket.txt | 320 | rocket.txt |
323 | - info on the Comtrol RocketPort multiport serial driver. | 321 | - info on the Comtrol RocketPort multiport serial driver. |
324 | rpc-cache.txt | ||
325 | - introduction to the caching mechanisms in the sunrpc layer. | ||
326 | rt-mutex-design.txt | 322 | rt-mutex-design.txt |
327 | - description of the RealTime mutex implementation design. | 323 | - description of the RealTime mutex implementation design. |
328 | rt-mutex.txt | 324 | rt-mutex.txt |
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 47a539c7642d..1fc4e7144dce 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches | |||
@@ -328,7 +328,7 @@ now, but you can do this to mark internal company procedures or just | |||
328 | point out some special detail about the sign-off. | 328 | point out some special detail about the sign-off. |
329 | 329 | ||
330 | 330 | ||
331 | 13) When to use Acked-by: | 331 | 13) When to use Acked-by: and Cc: |
332 | 332 | ||
333 | The Signed-off-by: tag indicates that the signer was involved in the | 333 | The Signed-off-by: tag indicates that the signer was involved in the |
334 | development of the patch, or that he/she was in the patch's delivery path. | 334 | development of the patch, or that he/she was in the patch's delivery path. |
@@ -349,11 +349,59 @@ Acked-by: does not necessarily indicate acknowledgement of the entire patch. | |||
349 | For example, if a patch affects multiple subsystems and has an Acked-by: from | 349 | For example, if a patch affects multiple subsystems and has an Acked-by: from |
350 | one subsystem maintainer then this usually indicates acknowledgement of just | 350 | one subsystem maintainer then this usually indicates acknowledgement of just |
351 | the part which affects that maintainer's code. Judgement should be used here. | 351 | the part which affects that maintainer's code. Judgement should be used here. |
352 | When in doubt people should refer to the original discussion in the mailing | 352 | When in doubt people should refer to the original discussion in the mailing |
353 | list archives. | 353 | list archives. |
354 | 354 | ||
355 | If a person has had the opportunity to comment on a patch, but has not | ||
356 | provided such comments, you may optionally add a "Cc:" tag to the patch. | ||
357 | This is the only tag which might be added without an explicit action by the | ||
358 | person it names. This tag documents that potentially interested parties | ||
359 | have been included in the discussion | ||
355 | 360 | ||
356 | 14) The canonical patch format | 361 | |
362 | 14) Using Test-by: and Reviewed-by: | ||
363 | |||
364 | A Tested-by: tag indicates that the patch has been successfully tested (in | ||
365 | some environment) by the person named. This tag informs maintainers that | ||
366 | some testing has been performed, provides a means to locate testers for | ||
367 | future patches, and ensures credit for the testers. | ||
368 | |||
369 | Reviewed-by:, instead, indicates that the patch has been reviewed and found | ||
370 | acceptable according to the Reviewer's Statement: | ||
371 | |||
372 | Reviewer's statement of oversight | ||
373 | |||
374 | By offering my Reviewed-by: tag, I state that: | ||
375 | |||
376 | (a) I have carried out a technical review of this patch to | ||
377 | evaluate its appropriateness and readiness for inclusion into | ||
378 | the mainline kernel. | ||
379 | |||
380 | (b) Any problems, concerns, or questions relating to the patch | ||
381 | have been communicated back to the submitter. I am satisfied | ||
382 | with the submitter's response to my comments. | ||
383 | |||
384 | (c) While there may be things that could be improved with this | ||
385 | submission, I believe that it is, at this time, (1) a | ||
386 | worthwhile modification to the kernel, and (2) free of known | ||
387 | issues which would argue against its inclusion. | ||
388 | |||
389 | (d) While I have reviewed the patch and believe it to be sound, I | ||
390 | do not (unless explicitly stated elsewhere) make any | ||
391 | warranties or guarantees that it will achieve its stated | ||
392 | purpose or function properly in any given situation. | ||
393 | |||
394 | A Reviewed-by tag is a statement of opinion that the patch is an | ||
395 | appropriate modification of the kernel without any remaining serious | ||
396 | technical issues. Any interested reviewer (who has done the work) can | ||
397 | offer a Reviewed-by tag for a patch. This tag serves to give credit to | ||
398 | reviewers and to inform maintainers of the degree of review which has been | ||
399 | done on the patch. Reviewed-by: tags, when supplied by reviewers known to | ||
400 | understand the subject area and to perform thorough reviews, will normally | ||
401 | increase the liklihood of your patch getting into the kernel. | ||
402 | |||
403 | |||
404 | 15) The canonical patch format | ||
357 | 405 | ||
358 | The canonical patch subject line is: | 406 | The canonical patch subject line is: |
359 | 407 | ||
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index e68021c08fbd..52cd611277a3 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX | |||
@@ -66,6 +66,8 @@ mandatory-locking.txt | |||
66 | - info on the Linux implementation of Sys V mandatory file locking. | 66 | - info on the Linux implementation of Sys V mandatory file locking. |
67 | ncpfs.txt | 67 | ncpfs.txt |
68 | - info on Novell Netware(tm) filesystem using NCP protocol. | 68 | - info on Novell Netware(tm) filesystem using NCP protocol. |
69 | nfsroot.txt | ||
70 | - short guide on setting up a diskless box with NFS root filesystem. | ||
69 | ntfs.txt | 71 | ntfs.txt |
70 | - info and mount options for the NTFS filesystem (Windows NT). | 72 | - info and mount options for the NTFS filesystem (Windows NT). |
71 | ocfs2.txt | 73 | ocfs2.txt |
@@ -82,6 +84,10 @@ relay.txt | |||
82 | - info on relay, for efficient streaming from kernel to user space. | 84 | - info on relay, for efficient streaming from kernel to user space. |
83 | romfs.txt | 85 | romfs.txt |
84 | - description of the ROMFS filesystem. | 86 | - description of the ROMFS filesystem. |
87 | rpc-cache.txt | ||
88 | - introduction to the caching mechanisms in the sunrpc layer. | ||
89 | seq_file.txt | ||
90 | - how to use the seq_file API | ||
85 | sharedsubtree.txt | 91 | sharedsubtree.txt |
86 | - a description of shared subtrees for namespaces. | 92 | - a description of shared subtrees for namespaces. |
87 | smbfs.txt | 93 | smbfs.txt |
diff --git a/Documentation/nfsroot.txt b/Documentation/filesystems/nfsroot.txt index 31b329172343..31b329172343 100644 --- a/Documentation/nfsroot.txt +++ b/Documentation/filesystems/nfsroot.txt | |||
diff --git a/Documentation/rpc-cache.txt b/Documentation/filesystems/rpc-cache.txt index 8a382bea6808..8a382bea6808 100644 --- a/Documentation/rpc-cache.txt +++ b/Documentation/filesystems/rpc-cache.txt | |||
diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt new file mode 100644 index 000000000000..7fb8e6dc62bf --- /dev/null +++ b/Documentation/filesystems/seq_file.txt | |||
@@ -0,0 +1,283 @@ | |||
1 | The seq_file interface | ||
2 | |||
3 | Copyright 2003 Jonathan Corbet <corbet@lwn.net> | ||
4 | This file is originally from the LWN.net Driver Porting series at | ||
5 | http://lwn.net/Articles/driver-porting/ | ||
6 | |||
7 | |||
8 | There are numerous ways for a device driver (or other kernel component) to | ||
9 | provide information to the user or system administrator. One useful | ||
10 | technique is the creation of virtual files, in debugfs, /proc or elsewhere. | ||
11 | Virtual files can provide human-readable output that is easy to get at | ||
12 | without any special utility programs; they can also make life easier for | ||
13 | script writers. It is not surprising that the use of virtual files has | ||
14 | grown over the years. | ||
15 | |||
16 | Creating those files correctly has always been a bit of a challenge, | ||
17 | however. It is not that hard to make a virtual file which returns a | ||
18 | string. But life gets trickier if the output is long - anything greater | ||
19 | than an application is likely to read in a single operation. Handling | ||
20 | multiple reads (and seeks) requires careful attention to the reader's | ||
21 | position within the virtual file - that position is, likely as not, in the | ||
22 | middle of a line of output. The kernel has traditionally had a number of | ||
23 | implementations that got this wrong. | ||
24 | |||
25 | The 2.6 kernel contains a set of functions (implemented by Alexander Viro) | ||
26 | which are designed to make it easy for virtual file creators to get it | ||
27 | right. | ||
28 | |||
29 | The seq_file interface is available via <linux/seq_file.h>. There are | ||
30 | three aspects to seq_file: | ||
31 | |||
32 | * An iterator interface which lets a virtual file implementation | ||
33 | step through the objects it is presenting. | ||
34 | |||
35 | * Some utility functions for formatting objects for output without | ||
36 | needing to worry about things like output buffers. | ||
37 | |||
38 | * A set of canned file_operations which implement most operations on | ||
39 | the virtual file. | ||
40 | |||
41 | We'll look at the seq_file interface via an extremely simple example: a | ||
42 | loadable module which creates a file called /proc/sequence. The file, when | ||
43 | read, simply produces a set of increasing integer values, one per line. The | ||
44 | sequence will continue until the user loses patience and finds something | ||
45 | better to do. The file is seekable, in that one can do something like the | ||
46 | following: | ||
47 | |||
48 | dd if=/proc/sequence of=out1 count=1 | ||
49 | dd if=/proc/sequence skip=1 out=out2 count=1 | ||
50 | |||
51 | Then concatenate the output files out1 and out2 and get the right | ||
52 | result. Yes, it is a thoroughly useless module, but the point is to show | ||
53 | how the mechanism works without getting lost in other details. (Those | ||
54 | wanting to see the full source for this module can find it at | ||
55 | http://lwn.net/Articles/22359/). | ||
56 | |||
57 | |||
58 | The iterator interface | ||
59 | |||
60 | Modules implementing a virtual file with seq_file must implement a simple | ||
61 | iterator object that allows stepping through the data of interest. | ||
62 | Iterators must be able to move to a specific position - like the file they | ||
63 | implement - but the interpretation of that position is up to the iterator | ||
64 | itself. A seq_file implementation that is formatting firewall rules, for | ||
65 | example, could interpret position N as the Nth rule in the chain. | ||
66 | Positioning can thus be done in whatever way makes the most sense for the | ||
67 | generator of the data, which need not be aware of how a position translates | ||
68 | to an offset in the virtual file. The one obvious exception is that a | ||
69 | position of zero should indicate the beginning of the file. | ||
70 | |||
71 | The /proc/sequence iterator just uses the count of the next number it | ||
72 | will output as its position. | ||
73 | |||
74 | Four functions must be implemented to make the iterator work. The first, | ||
75 | called start() takes a position as an argument and returns an iterator | ||
76 | which will start reading at that position. For our simple sequence example, | ||
77 | the start() function looks like: | ||
78 | |||
79 | static void *ct_seq_start(struct seq_file *s, loff_t *pos) | ||
80 | { | ||
81 | loff_t *spos = kmalloc(sizeof(loff_t), GFP_KERNEL); | ||
82 | if (! spos) | ||
83 | return NULL; | ||
84 | *spos = *pos; | ||
85 | return spos; | ||
86 | } | ||
87 | |||
88 | The entire data structure for this iterator is a single loff_t value | ||
89 | holding the current position. There is no upper bound for the sequence | ||
90 | iterator, but that will not be the case for most other seq_file | ||
91 | implementations; in most cases the start() function should check for a | ||
92 | "past end of file" condition and return NULL if need be. | ||
93 | |||
94 | For more complicated applications, the private field of the seq_file | ||
95 | structure can be used. There is also a special value which can be returned | ||
96 | by the start() function called SEQ_START_TOKEN; it can be used if you wish | ||
97 | to instruct your show() function (described below) to print a header at the | ||
98 | top of the output. SEQ_START_TOKEN should only be used if the offset is | ||
99 | zero, however. | ||
100 | |||
101 | The next function to implement is called, amazingly, next(); its job is to | ||
102 | move the iterator forward to the next position in the sequence. The | ||
103 | example module can simply increment the position by one; more useful | ||
104 | modules will do what is needed to step through some data structure. The | ||
105 | next() function returns a new iterator, or NULL if the sequence is | ||
106 | complete. Here's the example version: | ||
107 | |||
108 | static void *ct_seq_next(struct seq_file *s, void *v, loff_t *pos) | ||
109 | { | ||
110 | loff_t *spos = v; | ||
111 | *pos = ++*spos; | ||
112 | return spos; | ||
113 | } | ||
114 | |||
115 | The stop() function is called when iteration is complete; its job, of | ||
116 | course, is to clean up. If dynamic memory is allocated for the iterator, | ||
117 | stop() is the place to free it. | ||
118 | |||
119 | static void ct_seq_stop(struct seq_file *s, void *v) | ||
120 | { | ||
121 | kfree(v); | ||
122 | } | ||
123 | |||
124 | Finally, the show() function should format the object currently pointed to | ||
125 | by the iterator for output. It should return zero, or an error code if | ||
126 | something goes wrong. The example module's show() function is: | ||
127 | |||
128 | static int ct_seq_show(struct seq_file *s, void *v) | ||
129 | { | ||
130 | loff_t *spos = v; | ||
131 | seq_printf(s, "%lld\n", (long long)*spos); | ||
132 | return 0; | ||
133 | } | ||
134 | |||
135 | We will look at seq_printf() in a moment. But first, the definition of the | ||
136 | seq_file iterator is finished by creating a seq_operations structure with | ||
137 | the four functions we have just defined: | ||
138 | |||
139 | static const struct seq_operations ct_seq_ops = { | ||
140 | .start = ct_seq_start, | ||
141 | .next = ct_seq_next, | ||
142 | .stop = ct_seq_stop, | ||
143 | .show = ct_seq_show | ||
144 | }; | ||
145 | |||
146 | This structure will be needed to tie our iterator to the /proc file in | ||
147 | a little bit. | ||
148 | |||
149 | It's worth noting that the iterator value returned by start() and | ||
150 | manipulated by the other functions is considered to be completely opaque by | ||
151 | the seq_file code. It can thus be anything that is useful in stepping | ||
152 | through the data to be output. Counters can be useful, but it could also be | ||
153 | a direct pointer into an array or linked list. Anything goes, as long as | ||
154 | the programmer is aware that things can happen between calls to the | ||
155 | iterator function. However, the seq_file code (by design) will not sleep | ||
156 | between the calls to start() and stop(), so holding a lock during that time | ||
157 | is a reasonable thing to do. The seq_file code will also avoid taking any | ||
158 | other locks while the iterator is active. | ||
159 | |||
160 | |||
161 | Formatted output | ||
162 | |||
163 | The seq_file code manages positioning within the output created by the | ||
164 | iterator and getting it into the user's buffer. But, for that to work, that | ||
165 | output must be passed to the seq_file code. Some utility functions have | ||
166 | been defined which make this task easy. | ||
167 | |||
168 | Most code will simply use seq_printf(), which works pretty much like | ||
169 | printk(), but which requires the seq_file pointer as an argument. It is | ||
170 | common to ignore the return value from seq_printf(), but a function | ||
171 | producing complicated output may want to check that value and quit if | ||
172 | something non-zero is returned; an error return means that the seq_file | ||
173 | buffer has been filled and further output will be discarded. | ||
174 | |||
175 | For straight character output, the following functions may be used: | ||
176 | |||
177 | int seq_putc(struct seq_file *m, char c); | ||
178 | int seq_puts(struct seq_file *m, const char *s); | ||
179 | int seq_escape(struct seq_file *m, const char *s, const char *esc); | ||
180 | |||
181 | The first two output a single character and a string, just like one would | ||
182 | expect. seq_escape() is like seq_puts(), except that any character in s | ||
183 | which is in the string esc will be represented in octal form in the output. | ||
184 | |||
185 | There is also a function for printing filenames: | ||
186 | |||
187 | int seq_path(struct seq_file *m, struct path *path, char *esc); | ||
188 | |||
189 | Here, path indicates the file of interest, and esc is a set of characters | ||
190 | which should be escaped in the output. | ||
191 | |||
192 | |||
193 | Making it all work | ||
194 | |||
195 | So far, we have a nice set of functions which can produce output within the | ||
196 | seq_file system, but we have not yet turned them into a file that a user | ||
197 | can see. Creating a file within the kernel requires, of course, the | ||
198 | creation of a set of file_operations which implement the operations on that | ||
199 | file. The seq_file interface provides a set of canned operations which do | ||
200 | most of the work. The virtual file author still must implement the open() | ||
201 | method, however, to hook everything up. The open function is often a single | ||
202 | line, as in the example module: | ||
203 | |||
204 | static int ct_open(struct inode *inode, struct file *file) | ||
205 | { | ||
206 | return seq_open(file, &ct_seq_ops); | ||
207 | } | ||
208 | |||
209 | Here, the call to seq_open() takes the seq_operations structure we created | ||
210 | before, and gets set up to iterate through the virtual file. | ||
211 | |||
212 | On a successful open, seq_open() stores the struct seq_file pointer in | ||
213 | file->private_data. If you have an application where the same iterator can | ||
214 | be used for more than one file, you can store an arbitrary pointer in the | ||
215 | private field of the seq_file structure; that value can then be retrieved | ||
216 | by the iterator functions. | ||
217 | |||
218 | The other operations of interest - read(), llseek(), and release() - are | ||
219 | all implemented by the seq_file code itself. So a virtual file's | ||
220 | file_operations structure will look like: | ||
221 | |||
222 | static const struct file_operations ct_file_ops = { | ||
223 | .owner = THIS_MODULE, | ||
224 | .open = ct_open, | ||
225 | .read = seq_read, | ||
226 | .llseek = seq_lseek, | ||
227 | .release = seq_release | ||
228 | }; | ||
229 | |||
230 | There is also a seq_release_private() which passes the contents of the | ||
231 | seq_file private field to kfree() before releasing the structure. | ||
232 | |||
233 | The final step is the creation of the /proc file itself. In the example | ||
234 | code, that is done in the initialization code in the usual way: | ||
235 | |||
236 | static int ct_init(void) | ||
237 | { | ||
238 | struct proc_dir_entry *entry; | ||
239 | |||
240 | entry = create_proc_entry("sequence", 0, NULL); | ||
241 | if (entry) | ||
242 | entry->proc_fops = &ct_file_ops; | ||
243 | return 0; | ||
244 | } | ||
245 | |||
246 | module_init(ct_init); | ||
247 | |||
248 | And that is pretty much it. | ||
249 | |||
250 | |||
251 | seq_list | ||
252 | |||
253 | If your file will be iterating through a linked list, you may find these | ||
254 | routines useful: | ||
255 | |||
256 | struct list_head *seq_list_start(struct list_head *head, | ||
257 | loff_t pos); | ||
258 | struct list_head *seq_list_start_head(struct list_head *head, | ||
259 | loff_t pos); | ||
260 | struct list_head *seq_list_next(void *v, struct list_head *head, | ||
261 | loff_t *ppos); | ||
262 | |||
263 | These helpers will interpret pos as a position within the list and iterate | ||
264 | accordingly. Your start() and next() functions need only invoke the | ||
265 | seq_list_* helpers with a pointer to the appropriate list_head structure. | ||
266 | |||
267 | |||
268 | The extra-simple version | ||
269 | |||
270 | For extremely simple virtual files, there is an even easier interface. A | ||
271 | module can define only the show() function, which should create all the | ||
272 | output that the virtual file will contain. The file's open() method then | ||
273 | calls: | ||
274 | |||
275 | int single_open(struct file *file, | ||
276 | int (*show)(struct seq_file *m, void *p), | ||
277 | void *data); | ||
278 | |||
279 | When output time comes, the show() function will be called once. The data | ||
280 | value given to single_open() can be found in the private field of the | ||
281 | seq_file structure. When using single_open(), the programmer should use | ||
282 | single_release() instead of seq_release() in the file_operations structure | ||
283 | to avoid a memory leak. | ||
diff --git a/Documentation/hrtimers/highres.txt b/Documentation/hrtimers/highres.txt index ce0e9a91e157..a73ecf5b4bdb 100644 --- a/Documentation/hrtimers/highres.txt +++ b/Documentation/hrtimers/highres.txt | |||
@@ -98,7 +98,7 @@ System-level global event devices are used for the Linux periodic tick. Per-CPU | |||
98 | event devices are used to provide local CPU functionality such as process | 98 | event devices are used to provide local CPU functionality such as process |
99 | accounting, profiling, and high resolution timers. | 99 | accounting, profiling, and high resolution timers. |
100 | 100 | ||
101 | The management layer assignes one or more of the folliwing functions to a clock | 101 | The management layer assigns one or more of the following functions to a clock |
102 | event device: | 102 | event device: |
103 | - system global periodic tick (jiffies update) | 103 | - system global periodic tick (jiffies update) |
104 | - cpu local update_process_times | 104 | - cpu local update_process_times |
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 4cd1a5da80a4..dafd001bf833 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -375,6 +375,10 @@ and is between 256 and 4096 characters. It is defined in the file | |||
375 | ccw_timeout_log [S390] | 375 | ccw_timeout_log [S390] |
376 | See Documentation/s390/CommonIO for details. | 376 | See Documentation/s390/CommonIO for details. |
377 | 377 | ||
378 | cgroup_disable= [KNL] Disable a particular controller | ||
379 | Format: {name of the controller(s) to disable} | ||
380 | {Currently supported controllers - "memory"} | ||
381 | |||
378 | checkreqprot [SELINUX] Set initial checkreqprot flag value. | 382 | checkreqprot [SELINUX] Set initial checkreqprot flag value. |
379 | Format: { "0" | "1" } | 383 | Format: { "0" | "1" } |
380 | See security/selinux/Kconfig help text. | 384 | See security/selinux/Kconfig help text. |
@@ -840,7 +844,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
840 | arch/alpha/kernel/core_marvel.c. | 844 | arch/alpha/kernel/core_marvel.c. |
841 | 845 | ||
842 | ip= [IP_PNP] | 846 | ip= [IP_PNP] |
843 | See Documentation/nfsroot.txt. | 847 | See Documentation/filesystems/nfsroot.txt. |
844 | 848 | ||
845 | ip2= [HW] Set IO/IRQ pairs for up to 4 IntelliPort boards | 849 | ip2= [HW] Set IO/IRQ pairs for up to 4 IntelliPort boards |
846 | See comment before ip2_setup() in | 850 | See comment before ip2_setup() in |
@@ -1194,10 +1198,10 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1194 | file if at all. | 1198 | file if at all. |
1195 | 1199 | ||
1196 | nfsaddrs= [NFS] | 1200 | nfsaddrs= [NFS] |
1197 | See Documentation/nfsroot.txt. | 1201 | See Documentation/filesystems/nfsroot.txt. |
1198 | 1202 | ||
1199 | nfsroot= [NFS] nfs root filesystem for disk-less boxes. | 1203 | nfsroot= [NFS] nfs root filesystem for disk-less boxes. |
1200 | See Documentation/nfsroot.txt. | 1204 | See Documentation/filesystems/nfsroot.txt. |
1201 | 1205 | ||
1202 | nfs.callback_tcpport= | 1206 | nfs.callback_tcpport= |
1203 | [NFS] set the TCP port on which the NFSv4 callback | 1207 | [NFS] set the TCP port on which the NFSv4 callback |
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index f1b2de170929..641d2afacffa 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt | |||
@@ -281,10 +281,10 @@ solution for a couple of reasons: | |||
281 | sa_family_t can_family; | 281 | sa_family_t can_family; |
282 | int can_ifindex; | 282 | int can_ifindex; |
283 | union { | 283 | union { |
284 | struct { canid_t rx_id, tx_id; } tp16; | 284 | /* transport protocol class address info (e.g. ISOTP) */ |
285 | struct { canid_t rx_id, tx_id; } tp20; | 285 | struct { canid_t rx_id, tx_id; } tp; |
286 | struct { canid_t rx_id, tx_id; } mcnet; | 286 | |
287 | struct { canid_t rx_id, tx_id; } isotp; | 287 | /* reserved for future CAN protocols address information */ |
288 | } can_addr; | 288 | } can_addr; |
289 | }; | 289 | }; |
290 | 290 | ||
diff --git a/Documentation/scheduler/00-INDEX b/Documentation/scheduler/00-INDEX index b5f5ca069b2d..fc234d093fbf 100644 --- a/Documentation/scheduler/00-INDEX +++ b/Documentation/scheduler/00-INDEX | |||
@@ -12,5 +12,7 @@ sched-domains.txt | |||
12 | - information on scheduling domains. | 12 | - information on scheduling domains. |
13 | sched-nice-design.txt | 13 | sched-nice-design.txt |
14 | - How and why the scheduler's nice levels are implemented. | 14 | - How and why the scheduler's nice levels are implemented. |
15 | sched-rt-group.txt | ||
16 | - real-time group scheduling. | ||
15 | sched-stats.txt | 17 | sched-stats.txt |
16 | - information on schedstats (Linux Scheduler Statistics). | 18 | - information on schedstats (Linux Scheduler Statistics). |
diff --git a/Documentation/sched-rt-group.txt b/Documentation/scheduler/sched-rt-group.txt index 1c6332f4543c..1c6332f4543c 100644 --- a/Documentation/sched-rt-group.txt +++ b/Documentation/scheduler/sched-rt-group.txt | |||
diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index 8861e47e5a2d..6d5f18143c50 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary | |||
@@ -116,6 +116,13 @@ low order bit. So when a chip's timing diagram shows the clock | |||
116 | starting low (CPOL=0) and data stabilized for sampling during the | 116 | starting low (CPOL=0) and data stabilized for sampling during the |
117 | trailing clock edge (CPHA=1), that's SPI mode 1. | 117 | trailing clock edge (CPHA=1), that's SPI mode 1. |
118 | 118 | ||
119 | Note that the clock mode is relevant as soon as the chipselect goes | ||
120 | active. So the master must set the clock to inactive before selecting | ||
121 | a slave, and the slave can tell the chosen polarity by sampling the | ||
122 | clock level when its select line goes active. That's why many devices | ||
123 | support for example both modes 0 and 3: they don't care about polarity, | ||
124 | and alway clock data in/out on rising clock edges. | ||
125 | |||
119 | 126 | ||
120 | How do these driver programming interfaces work? | 127 | How do these driver programming interfaces work? |
121 | ------------------------------------------------ | 128 | ------------------------------------------------ |
@@ -379,8 +386,14 @@ any more such messages. | |||
379 | + when bidirectional reads and writes start ... by how its | 386 | + when bidirectional reads and writes start ... by how its |
380 | sequence of spi_transfer requests is arranged; | 387 | sequence of spi_transfer requests is arranged; |
381 | 388 | ||
389 | + which I/O buffers are used ... each spi_transfer wraps a | ||
390 | buffer for each transfer direction, supporting full duplex | ||
391 | (two pointers, maybe the same one in both cases) and half | ||
392 | duplex (one pointer is NULL) transfers; | ||
393 | |||
382 | + optionally defining short delays after transfers ... using | 394 | + optionally defining short delays after transfers ... using |
383 | the spi_transfer.delay_usecs setting; | 395 | the spi_transfer.delay_usecs setting (this delay can be the |
396 | only protocol effect, if the buffer length is zero); | ||
384 | 397 | ||
385 | + whether the chipselect becomes inactive after a transfer and | 398 | + whether the chipselect becomes inactive after a transfer and |
386 | any delay ... by using the spi_transfer.cs_change flag; | 399 | any delay ... by using the spi_transfer.cs_change flag; |
diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt index 471e75389778..619699dde593 100644 --- a/Documentation/spinlocks.txt +++ b/Documentation/spinlocks.txt | |||
@@ -5,6 +5,28 @@ Please use DEFINE_SPINLOCK()/DEFINE_RWLOCK() or | |||
5 | __SPIN_LOCK_UNLOCKED()/__RW_LOCK_UNLOCKED() as appropriate for static | 5 | __SPIN_LOCK_UNLOCKED()/__RW_LOCK_UNLOCKED() as appropriate for static |
6 | initialization. | 6 | initialization. |
7 | 7 | ||
8 | Most of the time, you can simply turn: | ||
9 | |||
10 | static spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED; | ||
11 | |||
12 | into: | ||
13 | |||
14 | static DEFINE_SPINLOCK(xxx_lock); | ||
15 | |||
16 | Static structure member variables go from: | ||
17 | |||
18 | struct foo bar { | ||
19 | .lock = SPIN_LOCK_UNLOCKED; | ||
20 | }; | ||
21 | |||
22 | to: | ||
23 | |||
24 | struct foo bar { | ||
25 | .lock = __SPIN_LOCK_UNLOCKED(bar.lock); | ||
26 | }; | ||
27 | |||
28 | Declaration of static rw_locks undergo a similar transformation. | ||
29 | |||
8 | Dynamic initialization, when necessary, may be performed as | 30 | Dynamic initialization, when necessary, may be performed as |
9 | demonstrated below. | 31 | demonstrated below. |
10 | 32 | ||
diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt index f962d01bea2a..3102b81bef88 100644 --- a/Documentation/vm/hugetlbpage.txt +++ b/Documentation/vm/hugetlbpage.txt | |||
@@ -88,10 +88,9 @@ hugepages from the buddy allocator, if the normal pool is exhausted. As | |||
88 | these surplus hugepages go out of use, they are freed back to the buddy | 88 | these surplus hugepages go out of use, they are freed back to the buddy |
89 | allocator. | 89 | allocator. |
90 | 90 | ||
91 | Caveat: Shrinking the pool via nr_hugepages while a surplus is in effect | 91 | Caveat: Shrinking the pool via nr_hugepages such that it becomes less |
92 | will allow the number of surplus huge pages to exceed the overcommit | 92 | than the number of hugepages in use will convert the balance to surplus |
93 | value, as the pool hugepages (which must have been in use for a surplus | 93 | huge pages even if it would exceed the overcommit value. As long as |
94 | hugepages to be allocated) will become surplus hugepages. As long as | ||
95 | this condition holds, however, no more surplus huge pages will be | 94 | this condition holds, however, no more surplus huge pages will be |
96 | allowed on the system until one of the two sysctls are increased | 95 | allowed on the system until one of the two sysctls are increased |
97 | sufficiently, or the surplus huge pages go out of use and are freed. | 96 | sufficiently, or the surplus huge pages go out of use and are freed. |