CODEWITHSUNDEEP
linux-kernellinux-device-driverkernel-module
binW
binW

Reputation: 13682

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?

Upvotes: 11

Views: 3690

Answers (5)

Ciro Santilli OurBigBook.com
Ciro Santilli OurBigBook.com

Reputation: 382672

Runnable examples of everything

Too much talk is making me bored!

Upvotes: 4

Sahil Singh
Sahil Singh

Reputation: 3787

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.

Upvotes: 4

Santi1986
Santi1986

Reputation: 493

This includes all types with examples :)

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

Upvotes: 4

user502515
user502515

Reputation: 4444

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)

Upvotes: 6

caf
caf

Reputation: 239011

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.

Upvotes: 10

Related Questions