"A month of sundays ago Ricky Beam wrote:"
> On Sat, 26 Feb 2000, Peter T. Breuer wrote:
>
> >From the mgadvd driver:
> (everything is a 'static struct proc_dir_entry')
>
> #if ( LINUX_VERSION_CODE < KERNEL_VERSION(2,3,29) )
> proc_register(&proc_root, &codec_proc_entry);
> #else
> MGACodec_ProcDirEntry = proc_mkdir("driver/mga", NULL);
> MGACodec_Entry_codec = create_proc_read_entry("codec", 0,
> MGACodec_ProcDirEntry, (read_proc_t*)&proc_read, NULL);
> MGACodec_Entry_debug = create_proc_read_entry("debug", 0,
> MGACodec_ProcDirEntry, (read_proc_t*)&proc_debug, NULL);
> #endif
This appears to be the trick [re: where did proc_register go to?]. And the
registered function now has to set eof=1 explicitly when it runs out of
data to supply.
> And, no, I do NOT like the kernel calling those functions more than once
> for a read. 'proc_debug' resets the hardware!
Mind you, my "larger than one page" reads are still working with this
call registration method, and they don't recalculate their data. Hmm ...
OK. You may not realize it, but if you set the *start value in your
routine to the number of bytes returned in that visit, then the next
call will expect you to return the number of bytes from then on (which
will be indicated by offset != 0 and = what it should be).
I.e. the function I registered looks like this, and is still working:
static int
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,29)
get_proc_config (char *page, char **start, off_t offset, int len, int * eof, void * data)
#else
get_proc_config (char *page, char **start, off_t offset, int len, int unused)
#endif
{
int count = 0; // chars output
// bsearch our internal table until we locate the internal offset
int i = proc_config_find (offset);
// now print as many entries as we can from there on
count = print_entries (page, i, len);
// tell the caller that this is a "long style" multipage read
*start = (char *) count;
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,3,29)
if (count <= 0)
*eof = 1;
#endif
return count;
}
No skips done in the receiver, as far as I can tell.
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 29 2000 - 21:00:17 EST