Communication between Linux kernel and user space program

5
votes

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!

2
csocketslinux-kernelipckernel-module
Look into the netlink API. – moshbear
@moshbear is spot on. Netlink is pretty appropriate for this task. – Brian Cain
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
Thanks @moshbear, it seems to be exactly what I need here :) – Santa Zhang
@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

2 Answers

5
votes

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.

5
votes

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.