diff options
author | C. Scott Ananian <cscott@laptop.org> | 2007-07-16 02:41:13 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-07-16 12:05:48 -0400 |
commit | 6b86e854f71600c809536502a0efa9d4e384fb23 (patch) | |
tree | 25696d6d1aa803547c525f90345bca85d5cc3ed2 /Documentation/DocBook/procfs-guide.tmpl | |
parent | f4895925976977aaeda26ee2a603a99f17db500b (diff) |
update procfs-guide doc of read_func
The procfs-guide claims that 'the parameter start doesn't seem to be used
anywhere in the kernel'. This is out of date. In linux/fs/proc/generic.c
we find a very nice description of the parameters to read_func. The
appended patch replaces the bogus description with this (as far as I know)
accurate one.
Cc: "Randy.Dunlap" <rdunlap@xenotime.net>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'Documentation/DocBook/procfs-guide.tmpl')
-rw-r--r-- | Documentation/DocBook/procfs-guide.tmpl | 82 |
1 files changed, 63 insertions, 19 deletions
diff --git a/Documentation/DocBook/procfs-guide.tmpl b/Documentation/DocBook/procfs-guide.tmpl index 45cad23efefa..2de84dc195a8 100644 --- a/Documentation/DocBook/procfs-guide.tmpl +++ b/Documentation/DocBook/procfs-guide.tmpl | |||
@@ -352,49 +352,93 @@ entry->write_proc = write_proc_foo; | |||
352 | <funcsynopsis> | 352 | <funcsynopsis> |
353 | <funcprototype> | 353 | <funcprototype> |
354 | <funcdef>int <function>read_func</function></funcdef> | 354 | <funcdef>int <function>read_func</function></funcdef> |
355 | <paramdef>char* <parameter>page</parameter></paramdef> | 355 | <paramdef>char* <parameter>buffer</parameter></paramdef> |
356 | <paramdef>char** <parameter>start</parameter></paramdef> | 356 | <paramdef>char** <parameter>start</parameter></paramdef> |
357 | <paramdef>off_t <parameter>off</parameter></paramdef> | 357 | <paramdef>off_t <parameter>off</parameter></paramdef> |
358 | <paramdef>int <parameter>count</parameter></paramdef> | 358 | <paramdef>int <parameter>count</parameter></paramdef> |
359 | <paramdef>int* <parameter>eof</parameter></paramdef> | 359 | <paramdef>int* <parameter>peof</parameter></paramdef> |
360 | <paramdef>void* <parameter>data</parameter></paramdef> | 360 | <paramdef>void* <parameter>data</parameter></paramdef> |
361 | </funcprototype> | 361 | </funcprototype> |
362 | </funcsynopsis> | 362 | </funcsynopsis> |
363 | 363 | ||
364 | <para> | 364 | <para> |
365 | The read function should write its information into the | 365 | The read function should write its information into the |
366 | <parameter>page</parameter>. For proper use, the function | 366 | <parameter>buffer</parameter>, which will be exactly |
367 | should start writing at an offset of | 367 | <literal>PAGE_SIZE</literal> bytes long. |
368 | <parameter>off</parameter> in <parameter>page</parameter> and | ||
369 | write at most <parameter>count</parameter> bytes, but because | ||
370 | most read functions are quite simple and only return a small | ||
371 | amount of information, these two parameters are usually | ||
372 | ignored (it breaks pagers like <literal>more</literal> and | ||
373 | <literal>less</literal>, but <literal>cat</literal> still | ||
374 | works). | ||
375 | </para> | 368 | </para> |
376 | 369 | ||
377 | <para> | 370 | <para> |
378 | If the <parameter>off</parameter> and | 371 | The parameter |
379 | <parameter>count</parameter> parameters are properly used, | 372 | <parameter>peof</parameter> should be used to signal that the |
380 | <parameter>eof</parameter> should be used to signal that the | ||
381 | end of the file has been reached by writing | 373 | end of the file has been reached by writing |
382 | <literal>1</literal> to the memory location | 374 | <literal>1</literal> to the memory location |
383 | <parameter>eof</parameter> points to. | 375 | <parameter>peof</parameter> points to. |
384 | </para> | 376 | </para> |
385 | 377 | ||
386 | <para> | 378 | <para> |
387 | The parameter <parameter>start</parameter> doesn't seem to be | 379 | The <parameter>data</parameter> |
388 | used anywhere in the kernel. The <parameter>data</parameter> | ||
389 | parameter can be used to create a single call back function for | 380 | parameter can be used to create a single call back function for |
390 | several files, see <xref linkend="usingdata"/>. | 381 | several files, see <xref linkend="usingdata"/>. |
391 | </para> | 382 | </para> |
392 | 383 | ||
393 | <para> | 384 | <para> |
394 | The <function>read_func</function> function must return the | 385 | The rest of the parameters and the return value are described |
395 | number of bytes written into the <parameter>page</parameter>. | 386 | by a comment in <filename>fs/proc/generic.c</filename> as follows: |
396 | </para> | 387 | </para> |
397 | 388 | ||
389 | <blockquote> | ||
390 | <para> | ||
391 | You have three ways to return data: | ||
392 | </para> | ||
393 | <orderedlist> | ||
394 | <listitem> | ||
395 | <para> | ||
396 | Leave <literal>*start = NULL</literal>. (This is the default.) | ||
397 | Put the data of the requested offset at that | ||
398 | offset within the buffer. Return the number (<literal>n</literal>) | ||
399 | of bytes there are from the beginning of the | ||
400 | buffer up to the last byte of data. If the | ||
401 | number of supplied bytes (<literal>= n - offset</literal>) is | ||
402 | greater than zero and you didn't signal eof | ||
403 | and the reader is prepared to take more data | ||
404 | you will be called again with the requested | ||
405 | offset advanced by the number of bytes | ||
406 | absorbed. This interface is useful for files | ||
407 | no larger than the buffer. | ||
408 | </para> | ||
409 | </listitem> | ||
410 | <listitem> | ||
411 | <para> | ||
412 | Set <literal>*start</literal> to an unsigned long value less than | ||
413 | the buffer address but greater than zero. | ||
414 | Put the data of the requested offset at the | ||
415 | beginning of the buffer. Return the number of | ||
416 | bytes of data placed there. If this number is | ||
417 | greater than zero and you didn't signal eof | ||
418 | and the reader is prepared to take more data | ||
419 | you will be called again with the requested | ||
420 | offset advanced by <literal>*start</literal>. This interface is | ||
421 | useful when you have a large file consisting | ||
422 | of a series of blocks which you want to count | ||
423 | and return as wholes. | ||
424 | (Hack by Paul.Russell@rustcorp.com.au) | ||
425 | </para> | ||
426 | </listitem> | ||
427 | <listitem> | ||
428 | <para> | ||
429 | Set <literal>*start</literal> to an address within the buffer. | ||
430 | Put the data of the requested offset at <literal>*start</literal>. | ||
431 | Return the number of bytes of data placed there. | ||
432 | If this number is greater than zero and you | ||
433 | didn't signal eof and the reader is prepared to | ||
434 | take more data you will be called again with the | ||
435 | requested offset advanced by the number of bytes | ||
436 | absorbed. | ||
437 | </para> | ||
438 | </listitem> | ||
439 | </orderedlist> | ||
440 | </blockquote> | ||
441 | |||
398 | <para> | 442 | <para> |
399 | <xref linkend="example"/> shows how to use a read call back | 443 | <xref linkend="example"/> shows how to use a read call back |
400 | function. | 444 | function. |