I'm writing a kernel module in Solaris and am looking for an efficient mechanism in Solaris 10 and/or Linux to communicate from a kernel module to an application in user space. The kernel module would need to send an event along with some data to the user space app. I would prefer to use a mechanism which is common to both Solaris and Linux
I have read about netlink sockets but dont think these are available in Solaris.
Any help would be appreciated and I would also ask if you could point me to a code example for the mechanism that you suggest.

Thanks...

Shared memory ?

If you are transferring data from a kernel level module, then you are writing something that fits the definition of a device driver.

Linux Device Drivers, third edition, by Corbet, Rubini, and Kroah, describes how to implement device drivers in Linux (and, by extension, in Solaris 10, because that is also, in fact, Linux). Actually, if Solaris 10 is the 2.4 kernel (I can't recall whether it is 2.4 or 2.6) then you should use the second edition, by Rubini, which is now freely available online.

As always, the Linux source is the ultimate authority on the structure of device drivers. It is also a handy source for examples, though I find much of the code a bit short of comments and therefore somewhat opaque. If you find a device driver hard to read, just try looking at a different one. There are thousands or tens of thousands of them available for your reading enjoyment.

The basic paradigm in Unices is that everything is a file. However, there are two classes of device drivers, character streams (like consoles and printers) and block devices (like disk drives). Even if your device produces a stream of blocks of data, you may wish to regard it as a stream device.

Once you have the device driver working, you open the device and read from it. You can read either in blocking or nonblocking mode. The simplest approach may be to have a reader thread reading from the device in blocking mode. The reader thread uses some signaling method, such as a semaphore, to communicate with the data consumer.

This method is efficient because all the data transfers are data driven. The device driver consumes no CPU until a hardware interrupt activates it. Your reader thread consumes no CPU until the next data block from the device driver activates it. Your data consumer consumes no CPU until the reader thread signals that data is available.

The "device driver" metaphor is, indeed, very good when you want to implement something like this.

Use a combination of signals and ioctl calls.

thanks for info. I was thinking in terms of using doors for performance reasons. Your thoughts?

I had not heard about doors, so I consulted The Oracle. It sounds like doors are somewhat special to Solaris. The drawback that I see here is that you may be restricting the choice of platforms that could support your application to Solaris, which is all ready a narrower field than any of the three most popular Linux distributions. Though I cannot see the future, I believe that the more durable choice of platforms is Linux. Solaris may or may not be around five or ten years down the road. I believe Linux will be around for twenty years or more, though probably in a much different form. Considering how much Linux device drivers have changed between 2.2 and 2.6, even if you write your application using Linux device drivers you may expect to need to update the driver structure considerably over the next twenty years as we progress to 256-bit 64-core CPUs running at what would look like, to us now, hundreds of GHz or a few THz.

"Efficiency" is probably an irrelevant consideration. The process will not take a significant amount of time to make the transition. Keep it simple.

Look at the entire /proc filesystem, for instance: an elegantly simple solution to a vexing problem. Plenty of source-code examples abound, within the Linux kernel.

A "virtual file" can read and write an unlimited amount of data. For example, ls -l /proc can handle an unlimited number of processes). You've got an easy and well-defined interface (read/write/ioctl) that is easy for both application programs and the kernel to work with.

if anyone has used the doors functions can you tell me if door_call() can be used from a kernel module?

thanks

Door_call is a system call and thus is intended by definition to be called by a userland application, not from a kernel module. The Solaris door API is designed to provide fast inter process communication. If you are adventurous, you might explore an undocumented kernel function (door_ki_create) that allows creating a door between the kernel and user processes.
http://src.opensolaris.org/source/xr...oor_sys.c#3420
Here is a (C++ ??) code that apparently uses it (don't ask me to explain what it does and how ...) :
http://src.opensolaris.org/source/xr...ateway.cc#1120

Of course, as already stated, this won't be portable to Linux. There was an attempt to implement that API to Linux but unfortunately, that project is no more updated since many years: http://ldoor.sourceforge.net/

You should put a smiley somewhere for this joke not to be taken too seriously, just in case. Of course the Solaris kernel and the Linux one are pretty foreign to each other for many reasons.

Good references about Solaris device drivers are here:
http://hub.opensolaris.org/bin/view/...evice_drivers/
http://docs.sun.com/app/docs/doc/816-4854