Newbie kernel question

[sbonar]

What is the best way for kernel <-> user space communication? Examples?

Thx

[jggimi]

You don't specify anything, so this answer is extremely generic:

The POSIX standard specifies many different communications methods. While most are Inter-process communication techniques (IPCs) , there are some IPC methods that include kernel communication, e.g.: Signals and Timers.

However, the most common method for a userland application to contact the kernel is via a syscall. http://en.wikipedia.org/wiki/System_call

If you ask a more specific question, you'll get a more specific answer.

[sbonar]

Sorry for being so generic.

To be more specific, I have a kernel driver that is collecting information. I also have a user-space app that wants to get that information. I know that a basic way for the user-space app to get the information is to use an IOCTL call, but I was wonder if there wasn't a more efficient way do this. For one thing, with the IOCTL, I have to poll every x secs to determine if there is any information to read, which is very inefficient.

Hope that helps

[jggimi]

It does help, thanks!

IIRC, ioctl(2) is an interface to special files (/dev entries). You might be able to continue using ioctl, as you have designed your program, but instead of polling continuously, add notification through kqueue(2)/kevent(2) instead. Or, perhaps you could abandon ioctl (since it was intended for device control, not information gathering) and consider using the suite of socket(2)-based syscalls.

[sbonar]

Thanks. Any good examples on how a kernel and user-spaced app can use socket calls to communicate? I've used sockets to communicate between 2 apps in user-space on 2 different machines, i.e. client-server, but never from kernel to user-space.

Thanks again.

[jggimi]

I haven't either.

Poking through use-cases, it appears socket(2) is for userland-userland communcation. Sorry to have mislead you.

(There is the project at http://ksocket.sourceforge.org, dating from 2007, but that is Linux-specific. There was the ECalls project at http://www.cc.gatech.edu/systems/pro...ux/ecalls.html, but that appears to have been an academic research project from 2000-2001. It generated three papers but no apparent software.)

Other thoughts:

The tun(4) driver is a way for userland programs to access the network stack. This might be applicable, but I would think that would only be if your driver is a network driver, and only if the data of interest are incoming or outgoing packets. The bpf(4) device is probably better for that, anyway.

FreeBSD -- you don't mention your OS -- has a kenv(2) call that allows a userland program to inspect and change kernel environment variables. It is in support of the kenv(1) userland utility.

[jggimi]

One last thing: The only user->kernel communication tool that I use regularly is PF (I'm an OpenBSD user). It has a pseudo device driver, pf(4), which use ioctl(2) syscalls. The userland program is pfctl(8).

So ioctl appears to be the right tool for the job.

Reviewing the source for the driver and the userland program may be helpful.

[sbonar]

The OS is NetBSD.

[jggimi]

pfctl(8)'s source code can be found here: http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/pfctl/

The pf(4) kernel driver's code can be found in here: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/

[BSDfan666]

I can't think of any other solution besides the ones recommended by jggimi.. either way, you're still going to have to poll the kernel in some way.

Perhaps the Berkeley Packet Interface (.. bpf(4)) and http://www.monkey.org/~provos/libevent/?

[jggimi]

I'd think kqueue/kevent would be easier to implement.

[TerryP]

A random thought while I wait for a *huge* rsync to finish:

use a pseudo device file for the driver to expose the information to the user space (assuming it actually does more then harvest information).

write a user-land program to query information through the device file (in terms of user interface: think ps, not top). I personally like a character device, and any kind you can read & write data from

Judging by your words, I assume your user-side program needs to be more like top, a program that regularly refreshes a display of the data; then like ps which just dumps it out ala batch job. If the data can be read from a device file related to your driver, the usual access control model can be used to control access to the data (through that file), and I would assume that you can use any of the available solutions to the "Hey, when there's something to read from this file, give me a shout!" problem. That should range from BSD kqueue()/kevent(), Linux inofity, and other OS-specifics, to the standard select()/poll(), and GOD knows how many libraries and packages; fam, gamin, their source codes, blah blah blah. Personally I would see if kqueue/kevent can be used with performance gains, then use it on systems that support the interface.



Thus, the problem would then be simplified from: how the hell do I send data from a 'kernel driver' to a user space app, down to 0/ implementing the device file and 1/ finding a suitable method of file system notification.




I'm sure the latter one has been done to death and back again; the former should have enough drivers available to examine how it can be done. If the kqueue interface is portable enough for your needs, take a look at the paper on it, check source code for various programs that have the same problem (monitoring a file for change), and take a look see at what options there are.




Call me a fool, a moron, or just a mad and insane geek - but I learned well at an early age, the value of breaking down complex problems into small simple to understand pieces. Living around computers has like wise made me appreciate simple, uniform, and easy to side-step interfaces....