Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

docs: filesystems: convert seq_file.txt to ReST

- Add a SPDX header;
- Add a document title;
- Adjust section titles;
- Some whitespace fixes and new line breaks;
- Mark literal blocks as such;
- Add it to filesystems/index.rst.

Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Link: https://lore.kernel.org/r/f950a0a56178ee05872ae2a2711a04d7af8ebb24.1588021877.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>

authored by

Mauro Carvalho Chehab and committed by
Jonathan Corbet
53a41d3e 9b6f151e

+38 -24
+1
Documentation/filesystems/index.rst
··· 32 32 mandatory-locking 33 33 mount_api 34 34 quota 35 + seq_file 35 36 36 37 automount-support 37 38
+37 -24
Documentation/filesystems/seq_file.txt Documentation/filesystems/seq_file.rst
··· 1 - The seq_file interface 1 + .. SPDX-License-Identifier: GPL-2.0 2 + 3 + ====================== 4 + The seq_file Interface 5 + ====================== 2 6 3 7 Copyright 2003 Jonathan Corbet <corbet@lwn.net> 8 + 4 9 This file is originally from the LWN.net Driver Porting series at 5 10 http://lwn.net/Articles/driver-porting/ 6 11 ··· 48 43 read, simply produces a set of increasing integer values, one per line. The 49 44 sequence will continue until the user loses patience and finds something 50 45 better to do. The file is seekable, in that one can do something like the 51 - following: 46 + following:: 52 47 53 48 dd if=/proc/sequence of=out1 count=1 54 49 dd if=/proc/sequence skip=1 of=out2 count=1 ··· 60 55 http://lwn.net/Articles/22359/). 61 56 62 57 Deprecated create_proc_entry 58 + ============================ 63 59 64 60 Note that the above article uses create_proc_entry which was removed in 65 - kernel 3.10. Current versions require the following update 61 + kernel 3.10. Current versions require the following update:: 66 62 67 - - entry = create_proc_entry("sequence", 0, NULL); 68 - - if (entry) 69 - - entry->proc_fops = &ct_file_ops; 70 - + entry = proc_create("sequence", 0, NULL, &ct_file_ops); 63 + - entry = create_proc_entry("sequence", 0, NULL); 64 + - if (entry) 65 + - entry->proc_fops = &ct_file_ops; 66 + + entry = proc_create("sequence", 0, NULL, &ct_file_ops); 71 67 72 68 The iterator interface 69 + ====================== 73 70 74 71 Modules implementing a virtual file with seq_file must implement an 75 72 iterator object that allows stepping through the data of interest ··· 106 99 the most recent pos used in the previous session. 107 100 108 101 For our simple sequence example, 109 - the start() function looks like: 102 + the start() function looks like:: 110 103 111 104 static void *ct_seq_start(struct seq_file *s, loff_t *pos) 112 105 { ··· 136 129 example module can simply increment the position by one; more useful 137 130 modules will do what is needed to step through some data structure. The 138 131 next() function returns a new iterator, or NULL if the sequence is 139 - complete. Here's the example version: 132 + complete. Here's the example version:: 140 133 141 134 static void *ct_seq_next(struct seq_file *s, void *v, loff_t *pos) 142 135 { ··· 148 141 The stop() function closes a session; its job, of course, is to clean 149 142 up. If dynamic memory is allocated for the iterator, stop() is the 150 143 place to free it; if a lock was taken by start(), stop() must release 151 - that lock. The value that *pos was set to by the last next() call 144 + that lock. The value that ``*pos`` was set to by the last next() call 152 145 before stop() is remembered, and used for the first start() call of 153 146 the next session unless lseek() has been called on the file; in that 154 - case next start() will be asked to start at position zero. 147 + case next start() will be asked to start at position zero:: 155 148 156 149 static void ct_seq_stop(struct seq_file *s, void *v) 157 150 { ··· 159 152 } 160 153 161 154 Finally, the show() function should format the object currently pointed to 162 - by the iterator for output. The example module's show() function is: 155 + by the iterator for output. The example module's show() function is:: 163 156 164 157 static int ct_seq_show(struct seq_file *s, void *v) 165 158 { ··· 176 169 177 170 We will look at seq_printf() in a moment. But first, the definition of the 178 171 seq_file iterator is finished by creating a seq_operations structure with 179 - the four functions we have just defined: 172 + the four functions we have just defined:: 180 173 181 174 static const struct seq_operations ct_seq_ops = { 182 175 .start = ct_seq_start, ··· 201 194 202 195 203 196 Formatted output 197 + ================ 204 198 205 199 The seq_file code manages positioning within the output created by the 206 200 iterator and getting it into the user's buffer. But, for that to work, that ··· 211 203 Most code will simply use seq_printf(), which works pretty much like 212 204 printk(), but which requires the seq_file pointer as an argument. 213 205 214 - For straight character output, the following functions may be used: 206 + For straight character output, the following functions may be used:: 215 207 216 208 seq_putc(struct seq_file *m, char c); 217 209 seq_puts(struct seq_file *m, const char *s); ··· 221 213 expect. seq_escape() is like seq_puts(), except that any character in s 222 214 which is in the string esc will be represented in octal form in the output. 223 215 224 - There are also a pair of functions for printing filenames: 216 + There are also a pair of functions for printing filenames:: 225 217 226 218 int seq_path(struct seq_file *m, const struct path *path, 227 219 const char *esc); ··· 234 226 root is desired, it can be used with seq_path_root(). If it turns out that 235 227 path cannot be reached from root, seq_path_root() returns SEQ_SKIP. 236 228 237 - A function producing complicated output may want to check 229 + A function producing complicated output may want to check:: 230 + 238 231 bool seq_has_overflowed(struct seq_file *m); 232 + 239 233 and avoid further seq_<output> calls if true is returned. 240 234 241 235 A true return from seq_has_overflowed means that the seq_file buffer will ··· 246 236 247 237 248 238 Making it all work 239 + ================== 249 240 250 241 So far, we have a nice set of functions which can produce output within the 251 242 seq_file system, but we have not yet turned them into a file that a user ··· 255 244 file. The seq_file interface provides a set of canned operations which do 256 245 most of the work. The virtual file author still must implement the open() 257 246 method, however, to hook everything up. The open function is often a single 258 - line, as in the example module: 247 + line, as in the example module:: 259 248 260 249 static int ct_open(struct inode *inode, struct file *file) 261 250 { ··· 274 263 There is also a wrapper function to seq_open() called seq_open_private(). It 275 264 kmallocs a zero filled block of memory and stores a pointer to it in the 276 265 private field of the seq_file structure, returning 0 on success. The 277 - block size is specified in a third parameter to the function, e.g.: 266 + block size is specified in a third parameter to the function, e.g.:: 278 267 279 268 static int ct_open(struct inode *inode, struct file *file) 280 269 { ··· 284 273 285 274 There is also a variant function, __seq_open_private(), which is functionally 286 275 identical except that, if successful, it returns the pointer to the allocated 287 - memory block, allowing further initialisation e.g.: 276 + memory block, allowing further initialisation e.g.:: 288 277 289 278 static int ct_open(struct inode *inode, struct file *file) 290 279 { ··· 306 295 307 296 The other operations of interest - read(), llseek(), and release() - are 308 297 all implemented by the seq_file code itself. So a virtual file's 309 - file_operations structure will look like: 298 + file_operations structure will look like:: 310 299 311 300 static const struct file_operations ct_file_ops = { 312 301 .owner = THIS_MODULE, ··· 320 309 seq_file private field to kfree() before releasing the structure. 321 310 322 311 The final step is the creation of the /proc file itself. In the example 323 - code, that is done in the initialization code in the usual way: 312 + code, that is done in the initialization code in the usual way:: 324 313 325 314 static int ct_init(void) 326 315 { ··· 336 325 337 326 338 327 seq_list 328 + ======== 339 329 340 330 If your file will be iterating through a linked list, you may find these 341 - routines useful: 331 + routines useful:: 342 332 343 333 struct list_head *seq_list_start(struct list_head *head, 344 334 loff_t pos); ··· 350 338 351 339 These helpers will interpret pos as a position within the list and iterate 352 340 accordingly. Your start() and next() functions need only invoke the 353 - seq_list_* helpers with a pointer to the appropriate list_head structure. 341 + ``seq_list_*`` helpers with a pointer to the appropriate list_head structure. 354 342 355 343 356 344 The extra-simple version 345 + ======================== 357 346 358 347 For extremely simple virtual files, there is an even easier interface. A 359 348 module can define only the show() function, which should create all the 360 349 output that the virtual file will contain. The file's open() method then 361 - calls: 350 + calls:: 362 351 363 352 int single_open(struct file *file, 364 353 int (*show)(struct seq_file *m, void *p),