Are there any other interfaces, e.g. the /proc filesystem?
2 Answers
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
-
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. Sep 1, 2019 at 11:14
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
)
-
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?– user732Apr 15, 2014 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...– derobertApr 15, 2014 at 18:14
-
2Put
silly
as global variable and make it itself volatile as well, and no sane compiler will optimize it, because it cannot know whethersilly
will be mapped to a memory-mapped I/O region during linking, in which case reading silly may not recover the0
previously stored in it, but might actually deliver a valid address.– celtschkApr 15, 2014 at 20:30
/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.