Linux kernel /proc FIFO/pipe

Question

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.

Answer 1

/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.

Answer 2

There are some good suggestions. There are a number of ways supported by the kernel:

• character / block device suggested by Ana betts, and Michael Trausch
• mmap device (you can access as /proc/memshare/mybuffer for example)
• custom system. Writing a kernel module means you can really make your own method of access to the proc object. There are many samples in the kernel of this.

Hope this helps.

Answer 3

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.

Answer 4

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. :-)

Answer 5

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.