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

[Nicolas Pitre]

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.

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