Access the Linux kernel using the /proc filesystem (developerWorks) [LWN.net]

developerWorks offers a tutorial on creating /proc files from loadable kernel modules. "Here's a [module] that supports both reading and writing. This simple application provides a fortune cookie dispenser. After the module is loaded, the user can load text fortunes into it using the echo command and then read them back out individually using the cat command." Just don't try to get it merged into the mainline.

(Log in to post comments)

Access the Linux kernel using the /proc filesystem (developerWorks)

Posted Mar 15, 2006 15:45 UTC (Wed) by nix (subscriber, #2304) [Link]

I'll say not. It's tripped over a class of bug recently mentioned on l-k in the context of /proc/uptime... notably, fseek()ing on that file, even one byte in, and then read()ing it returns EOF, and truncated reads and reads into small buffers fail because the second read() will return EOF, even if a longer read() would have worked. This is, um, rather non-POSIXish

This is a classic case of something that should be using the seq_file interface.

Access the Linux kernel using the /proc filesystem (developerWorks)

Posted Mar 15, 2006 20:56 UTC (Wed) by sanjoy (subscriber, #5026) [Link]

Hmm, I'd noticed that

$ cat /proc/acpi/debug_level

produces only 1024 bytes of output. But

$ cat /proc/acpi/debug_level | cat

works, presumably because 'cat' uses bigger buffers when writing to a non-tty. But the first question is why the 'cat' fails. I thought the ACPI code was at fault, and I posted a patch but never got any word about it.

Your comment makes me think that the real problem may be in the kernel.

Access the Linux kernel using the /proc filesystem (developerWorks)

Posted Mar 16, 2006 10:30 UTC (Thu) by nix (subscriber, #2304) [Link]

Your patch does half of what is necessary, but note that with it applied, calling code takes no notice of the offset at all! So read(), lseek(..., 1, SEEK_SET), read() will return the same data twice...

seq_file does all this crud for you (that's what it's for) and /proc files consisting of semi-static data lumps without magic behaviour on read() (i.e., most of them) should probably be generated with it.