On Thu, 8 Sep 2016, Josh Triplett wrote: > On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > > On Thu, Sep 8, 2016 at 2:05 PM, Nicolas Pitre <[email protected]> wrote: > > > Small embedded systems typically don't need them. This removes about > > > 16KB from the kernel binary size on ARM when configured out. > > > Corresponding syscalls are routed to a stub logging the attempt to > > > use those syscalls which should be enough of a clue if they were > > > disabled without proper consideration. > > > > > > Signed-off-by: Nicolas Pitre <[email protected]> > > > > Hrm... So being able to trim down the kernel is important. > > > > Although my sense is that momentum has been moving to clock_gettime() > > over gettimeofday(), such that gettimeofday() is mostly a shim over > > clock_gettime() logic wise. So this is sort of going the other > > direction. > > > > Also given many other syscalls take clockids and the backing logic > > isn't really getting removed (probably could cut the dynamic posix > > clocks core with the same conditional), I wonder if you could get a > > similar size win by taking a slightly more narrow cutting of the > > subsystem. That way you could preserve the more useful clock_gettime() > > functionality, but maybe stub out some of the less often used > > functionality. > > I agree with this. Cutting out the syscall alone helps, but cutting out > the corresponding infrastructure for those timers would help even more. > I wouldn't suggest turning down this patch in isolation, but I'd very > much like to see it become a patch series that also removes the > underlying timer infrastructure.
The patch does remove more than only syscalls which are in posix-timers.c. The whole of posix-timers.c, posix-clock.c and posix-cpu-timers.c are removed. The later is particularly footprint heavy for one specialized clock type. > > Josh (cc'ed) also was talking awhile back about cutting out the core > > NTP logic. Having a single minimal-time option might be nice rather > > then having a bunch of different conditionals that might be combined. > > I do think having individual configuration options for families of > syscalls helps, in that people can more easily figure out the set of > syscalls their code calls. But those options should also cut out the > underlying infrastructure whenever possible; that avoids the need to > have separate options for the infrastructure, which a user would have to > enable to see the options for the interfaces to that infrastructure. If > it can't get called, it doesn't need compiling in. Absolutely. However this is something that would scale better with automatic code pruning performed by LTO or ld with -gc-sections. > If that infrastructure supports multiple families of syscalls that make > sense to drop independently, then it might make sense to have that > underlying option, ideally automatically selected. For instance, a > legacy-free userspace might only enable signalfd and not traditional > signal delivery, or only enable timerfd and not enable other forms of > timers. One problem is that embedded libc implementations often go with the legacy interface as it is often simpler and smaller. > (Hopefully the kconfig-sat folks can successfully develop a system that > allows you to turn on an option whose dependencies aren't yet enabled > and automatically enable its dependencies, to improve the functionality > of "select".) > > For this patch, I'd recommend expanding the documentation for the > Kconfig symbol to explicitly state the families of syscalls this omits. Good point. > I'd also suggest dropping the stubs that print a message, and just using > sys_ni_syscall. As a debug mechanism, that infrastructure seems more > generally useful than just POSIX timer syscalls. Instead, I'd suggest a > separate patch adding (optional, CONFIG_SHOW_MISSING_SYSCALLS) support > in sys_ni.c to print a one-time message per syscall showing the process > name, PID, syscall number, name, and Kconfig symbol needed to enable it. > You could modify cond_syscall to accept a Kconfig symbol argument, and > generate a unique stub that calls printk_once. Yes, this would be a good thing to have. The ptrace infrastructure might be leveraged here simply to get the actual syscall number, etc. However I wouldn't start on that unless there is actually some more configurable syscalls making the rationalization worth it. Here I wanted to have a minimal printout in case someone decided to turn off POSIX timers and wondered why his big desktop distro doesn't boot anymore. Those syscalls have never been optional before. Nicolas
