Re: [RFC/PATCH] posix-timers: make them configurable

[Josh Triplett]

On Thu, Sep 08, 2016 at 07:56:28PM -0400, Nicolas Pitre wrote:
> 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 <nico@xxxxxxxxxxx> 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@xxxxxxxxxx>
> > > 
> > > 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.

Looking at this again, it looks like this *does* already cut out the
dynamic POSIX clocks core that John Stultz mentioned, unless I'm missing
something.  John, what did you have in mind here?

And which other syscalls did you have in mind that take a clockid_t?

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

Agreed, that may help eliminate some internal-only selected Kconfig
options eventually.

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

In some cases, yes.  But, for instance, signalfd needs significantly
less infrastructure than traditional signals/sigreturn/etc.

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

Assuming you have the ptrace infrastructure. :)  But yes, looking up the
syscall number in a table might work better, though it'd add complexity
versus just generating multiple stubs.

> However I wouldn't start on that unless there is actually some more 
> configurable syscalls making the rationalization worth it.

Many other syscalls have Kconfig options; this would help with those
too.

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

I agree; I'd just prefer to see the general version rather than a
syscall-specific solution.

- Josh Triplett