views:

1142

answers:

4

I'm currently trying to create a kernel module that will produce data based on kernel events and push them to a file. After reading that this is bad (and I agree), I decided it would make more sense to have the data in a /proc file that a user program could pull from when necessary. However, this idea led to all sorts of problems, particularly when and how to clear out this file. So I thought... "why don't I make a named pipe in /proc and read from that?"

I've got the general gist of setting a read function and a write function for a proc file, but I'm still having conceptual trouble with how I'd go about this. Namely, how would I write such a function to take arbitrary data and write it to such a pipe from the kernel? Does anyone have any idea how you'd push data to a named pipe from kernel-space? In the end, it doesn't have to be a /proc file (particularly if it's wrong of me to do so), but that was the conclusion I came to. Then I'll have to figure out how to attach to it from a userspace program, but I feel that's a separate issue.

+3  A: 

Instead of making a named pipe, what you want to do is create a "Character device". If you want simple interaction or streaming data from kernel to userspace and back, this is the usual method. I'd recommend looking up similar devices in the Linux kernel and seeing what they do.

Paul Betts
A: 

I agree with Paul—implementing a character device is probably the best way to go. Maybe looking at the code implementing /dev/kmem or /dev/rtc[0-9]. Also, the serial drivers implement their drivers using character devices.

Just think of it as a virtual device. :-)

Michael Trausch
A: 

/proc isn't actually a real file system; it's constructed by the kernel based on what's currently running. I don't think you can create named pipes in it.

R. Bemrose
You can in fact *create* them (I did), though I'm not sure how functional they are.
Dan Fego
A: 

I think the way this is generally done is to use a netlink socket; one or more userspace processes can bind to a "netlink" address, and your kernel facility can broadcast messages to any / all of them as necessary.

This is certainly what some things do, the networking subsystem especially. It is possible for a userspace program to watch for changes in network interfaces (e.g. new IP addresses, link status change) using this method.

MarkR