Message-ID: <20160908214800.anft4fzmjpmoew4j@x>
Date:   Thu, 8 Sep 2016 14:48:00 -0700
From:   Josh Triplett <josh@...htriplett.org>
To:     John Stultz <john.stultz@...aro.org>
Cc:     Nicolas Pitre <nico@...xnic.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        lkml <linux-kernel@...r.kernel.org>,
        Richard Cochran <richardcochran@...il.com>
Subject: Re: [RFC/PATCH] posix-timers: make them configurable

On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote:
> On Thu, Sep 8, 2016 at 2:05 PM, Nicolas Pitre <nico@...xnic.net> 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 <nico@...aro.org>
> 
> 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.

> 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.

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.

(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.

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.

This infrastructure would itself take up space, and wouldn't make any
sense without CONFIG_PRINTK, hence making it optional.  But as a
debugging mechanism when working on shrinking a kernel for a target
application, it seems quite useful.  (The only caveat: a message
wouldn't always indicate a problem, since an application may handle
ENOSYS.)

Powered by blists - more mailing lists