7

I'm currently writing a Linux kernel module, and have problems implementing its communication with user space programs.

This kernel module needs to receive tasks issued by a user space program, and send results back to user space program after completion. The user space program should be blocked while the kernel module is doing its job.

I think a kernel-user space IPC or an Unix socket would be sweet, but I had no luck finding an example by Google.

Currently my ugly solution is to export a chardev and let user space program write requests to the device file, and read results from it. But I can only issue one request per open() call, and this is causing new problems. I really need an IPC or socket-like thing. Thanks!

Santa Zhang
  • 884
  • 8
  • 13
  • 7
    Look into the netlink API. – moshbear Nov 16 '11 at 02:41
  • @moshbear is spot on. Netlink is pretty appropriate for this task. – Brian Cain Nov 16 '11 at 03:01
  • `chardev` sounds good to me. Why can you issue only one request per open(2)? Why not one request per write(2) and get results back with read(2)? The user process will be blocked in read(2) while your module is sending data. Where is your problem? – Mackie Messer Nov 16 '11 at 03:01
  • Thanks @moshbear, it seems to be exactly what I need here :) – Santa Zhang Nov 16 '11 at 03:23
  • @MackieMesser Yes, this will work, but I have to check if the `write(2)` call has written a complete message. If the user program uses `fprintf()` to write requests to `chardev`, then the kernel module might receive partial messages. By using sockets or IPC, I think I could guarantee the message to be complete. – Santa Zhang Nov 16 '11 at 03:26
  • @SantaZhang: Well, you will need extensive tests in the kernel for complete/valid messages anyway. You could offer a user level library to people who want to use your module and thereby prevent incorrect usage with fprintf(). But if you are more confortable with netlink, there is nothing wrong with that either! :-) – Mackie Messer Nov 16 '11 at 04:41

2 Answers2

6

There are several ways to implement this.

The easiest is to use the proc file interface to communicate, especially if the message and the result are less than one page in size.

General Sequence would be as under:

  • Implement proc_open(), proc_read() and proc_write(); proc_close();

  • Open and close can implement locking so that only one instance of userspace program can actually access the module request engine.

  • the task request is sent via a write to the proc file,

  • The write function will return successfully if the module understands the command, before returning the program will initialize the request processing, the processing can actually take place when the proc file is read if it is trivial. If the processing is significantly complex then i suggest that you read up on bottom halves1 (you can simply start a working queue).

  • The read either triggers the "processing you want the module to do". or waits for the BH to finish the processing in case you do it that way. You can use a spinlock or a mutex to control flow.

  • The kernel processing returns the result upon completion.

Ahmed Masud
  • 21,655
  • 3
  • 33
  • 58
6

Instead of using normal sockets, proc fs and implementing a new system call, Use netlink sockets which offers full duplex communication between user space programs and kernel modules.

vajja
  • 61
  • 1