Re: [Ksummit-discuss] [CORE TOPIC] Kernel tinification: shrinking the kernel and avoiding size regressions

[Theodore Ts'o <tytso@mit.edu>]

There's been a huge focus on system calls in this discussion, and I
suspect this is a bit of a red herring.  Taking a look at "git log
arch/x86/syscalls/syscall_64.tbl" --- since all the world's is no
longer a Vax, but rather an x86_64 :-P --- there really hasn't been
that many new system calls lately.  Yes, we recently added
renameat(2), but the next addition was half a year earlier, when the
new schedular parameters syscalls went in.

There's much more in the way of kernel functionality and complexity
which isn't really syscall related --- for example, all of the control
group stuff, and security hair caused by things like user namespaces,
and new fallocate(2) modes --- we've added PUNCH_HOLE, COLLAPSE_RANGE,
and ZERO_RANGE, and there are threats to add INSERT_RANGE in the next
release or two.

And if you look at things like renameat(2), the actual code savings by
removing renameat(2) is pretty small, and IMHO, not worth the
complexity and uncertainty that it would represent to application
programmers of "does this system call exist or doesn't it".

In contrast, if you want to take at the bloat and complexity added by
the pluggable security LSM's, control groups, and name spaces, the
comparison isn't even close.  Furthermore, given that low level
progams programs like systemd have grown to require control groups,
it's not like you can even realistically strip it from potentially
even many embedded kernels, since there seems to be a movement to have
systemd infect even smaller embedded applications.

Anyone want to lay odds on when systemd will start using various
namespaces for its own purposes?  :-)

						- Ted