4

Are there any other interfaces, e.g. the /proc filesystem?

1
  • 1
    Even /proc and /sys involve system calls in order to open, write and close files so I'm leaning towards a negatory on that one. I don't know for sure, so I'm not posting an answer, but anything I can think of would require a syscall be made at some point. – Bratchley Apr 15 '14 at 16:57
11

The Linux kernel syscall API is the the primary API (though hidden under libc, and rarely used directly by programmers), and most standard IPC mechanisms are heavily biased toward the everything is a file approach, which eliminates them here as they ultimately require read/write (and more) calls.

However, on most platforms (if you exclude all the system calls to get you there) there is a way: VDSO. This is a mechanism where the kernel maps one (or more) slightly magic pages into each process (usually in the form of an ELF .so). You can see this as linux-vdso.so or similar with ldd or in /proc/PID/maps. This is effectively memory-mapped IPC between the kernel and a user process (albeit one-way in its current implementation).

It's used to speed up syscalls in general and was originally implemented (linux-gate.so) to address x86 performance issues, but it may also contain kernel data and access functions. Calls like getcpu() and gettimeofday() may use these rather than making an actual syscall and a kernel context switch. The availability of these optimised calls is detected and enabled by the glibc startup code (subject to platform availability). Current implementations contain a (read-only) page of shared kernel variables known as the "VVAR" page which can be read directly.

You can check this by inspecting the output of strace -e trace=clock_gettime date to see if your date command makes any clock_gettime() syscalls, with a working VDSO it will not (the time will be read from the VVARS page by a function in the VDSO page, see arch/x86/vdso/vclock_gettime.c).

There's a useful technical summary here: http://blog.tinola.com/?e=5 a more detailed tutorial: http://www.linuxjournal.com/content/creating-vdso-colonels-other-chicken , and the man page: http://man7.org/linux/man-pages/man7/vdso.7.html

1
  • The linux kernel also has ringbuffer and "memory mapped" interfaces. Some that come to mind: io_uring_setup(2) in polling mode, set_robust_list(2). Maybe there are others too. – textshell Sep 1 '19 at 11:14
9

No.

Trivial counter example, this will interact with the kernel:

int main() {
    volatile char *silly = 0;
    *silly = 'a';
}

That'll call the kernel's page fault handler, ultimately resulting in your process getting a SIGSEGV (presuming the compiler doesn't "optimize" that code to do something other than the obvious, since that's undefined behavior by the C standard, make sure to compile with -O0)

3
  • That seems almost vacuous. If we count hardware traps into the kernel, then a busy loop which just eats an entire time-slice counts as "interacting" with the kernel, doesn't it? – Bruce Ediger Apr 15 '14 at 18:09
  • @BruceEdiger this causes a signal to be raised, which seems more interacting than the scheduling interrupt, which is mostly transparent to the process. It does as much as the kill syscall would... – derobert Apr 15 '14 at 18:14
  • 2
    Put silly as global variable and make it itself volatile as well, and no sane compiler will optimize it, because it cannot know whether silly will be mapped to a memory-mapped I/O region during linking, in which case reading silly may not recover the 0 previously stored in it, but might actually deliver a valid address. – celtschk Apr 15 '14 at 20:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.