What options do we have for communication between a user program and a Linux Kernel Module?

I am a new comer开发者_运维知识库 to Linux Kernel Module programming. From the material that I have read so far, I have found that there are 3 ways for a user program to request services or to communicate with a Linux Kernel Module

1. a device file in /dev
2. a file in /proc file system
3. ioctl() call

Question: What other options do we have for communication between user program and linux kernel module?

---

Your option 3) is really a sub-option of option 1) - ioctl() is one way of interacting with a device file (read() and write() being the usual ways).

Two other ways worth considering are:

• The sysfs filesystem;
• Netlink sockets.

---

Basically, many standard IPC mechanisms — cf. http://en.wikipedia.org/wiki/Inter-process_communication — can be used:

1. File and memory-mapped file: a device file (as above) or similarly special file in /dev, procfs, sysfs, debugfs, or a filesystem of your own, cartesian product with read/write, ioctl, mmap

2. Possibly signals (for use with a kthread)

3. Sockets: using a protocol of choice: TCP, UDP (cf. knfsd, but likely not too easy), PF_LOCAL, or Netlink (many subinterfaces - base netlink, genetlink, Connector, ...)

Furthermore,

 4. System calls (not really usable from modules though)

 5. Network interfaces (akin to tun).

Working examples of Netlink — just to name a few — can be found for example in

• git://git.netfilter.org/libmnl (userspace side)
• net/core/rtnetlink.c (base netlink)
• net/netfilter/nf_conntrack_netlink.c (nfnetlink)
• fs/quota/netlink.c (genetlink)

---

This includes all types with examples :)

http://people.ee.ethz.ch/~arkeller/linux/kernel_user_space_howto.html

---

Runnable examples of everything

Too much talk is making me bored!

• file operations:

  • file types that implement file operations:

    • procfs. See also: proc_create() example for kernel module
    • debugfs
    • character devices. See also: https://unix.stackexchange.com/questions/37829/how-do-character-device-or-character-special-files-work/371758#371758
    • sysfs. See also: How to attach file operations to sysfs attribute in platform driver?

  • file operation syscalls themselves

    • open, read, write, close, lseek. See also: How to add poll function to the kernel module code?
    • poll. See also: How do I use ioctl() to manipulate my kernel module?
    • ioctl. See also: How do I use ioctl() to manipulate my kernel module?
    • mmap. See also: How to mmap a Linux kernel buffer to user space?
    • anonymous inodes. See also: What is an anonymous inode in Linux?

• netlink sockets. See also: How to use netlink socket to communicate with a kernel module?

---

This Linux document gives some of the ways in which the kernel and user space can interact(communicate). They are the following.

• Procfs, sysfs, and similar mechanisms. This includes /dev entries as well, and all the methods in which kernel space exposes a file in user space (/proc, /dev, etc. entries are basically files exposed from the kernel space).
• Socket based mechanisms. Netlink is a type of socket, which is meant specially for communication between user space and kernel space.
• System calls.
• Upcalls. The kernel executes a code in user space. For example spawning a new process.
• mmap - Memory mapping a region of kernel memory to user space. This allows both the kernel, and the user space to read/write to the same memory area.

Other than these, the following list adds some other mechanisms I know.

• Interrupts. The user space can raise interrupts to talk to kernel space. For example some CPUs use int80 to make system calls (while others may use a different mechanism like syscall instruction). The kernel has to define the corresponding interrupt handler in advance.
• vDSO/vsyscall - These are mechanisms in Linux kernel to optimize execution of some system calls. The idea is to have a shared memory region, and when a process makes a system call, the user space library gets data from this region, instead of actually calling the corresponding system call. This saves context switch overhead.