Re: [PATCH v2) posix-timers: make it configurable

[Josh Triplett <josh@joshtriplett.org>]

On Wed, Sep 14, 2016 at 05:09:53PM -0400, Nicolas Pitre wrote:
> On Wed, 14 Sep 2016, Josh Triplett wrote:
> 
> > On Wed, Sep 14, 2016 at 04:46:54PM -0400, Nicolas Pitre wrote:
> > > Many embedded systems typically don't need them.  This removes about
> > > 22KB 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. They are: timer_create,
> > > timer_gettime: timer_getoverrun, timer_settime, timer_delete,
> > > clock_adjtime.
> > > 
> > > The clock_settime, clock_gettime, clock_getres and clock_nanosleep syscalls
> > > are replaced by simple wrappers compatible with CLOCK_REALTIME,
> > > CLOCK_MONOTONIC and CLOCK_BOOTTIME only.
> > > 
> > > Signed-off-by: Nicolas Pitre <nico@linaro.org>
> > > ---
> > > 
> > > Changes from RFC/v1:
> > > 
> > > - Stubbed-out functions moved to static inlines.
> > > - The timer signal handling code is now removed.
> > > - The list of removed syscalls is explicitly documented.
> > > - The clock_settime, clock_gettime, clock_getres and clock_nanosleep 
> > >   syscalls are minimally preserved as this required very little code.
> > > 
> > > I'm now able to boot a copy of Fedora 21 with this patch and 
> > > CONFIG_POSIX_TIMERS=n with no apparent issues.
> > 
> > This looks quite reasonable.
> > 
> > Does booting a standard distro really require providing clock_settime?
> 
> I don't know.  Maybe some date(1) implementation uses it. It is however 
> so small that there is no real advantage in explicitly removing it.

True at the moment, though dropping it may in the future allow dropping
more of the underlying time infrastructure itself.

> > I'd still prefer to see the special-case sys_ni support dropped,
> > especially since the most common syscalls now remain.  However, if
> > others want to see it kept, I won't object too strongly; whoever ends up
> > implementing a common (and optional) version of that infrastructure for
> > all syscalls can fold this into it.
> 
> Personally, I'd prefer to see more of those configurable syscalls before 
> introducing such infrastructure.

See kernel/sys_ni.c for a *long* list of configurable syscalls,
including widely used syscalls.  (Sockets, UIDs/GIDs, futexes, epoll,
etc)  Those already seem like enough to justify a "this application
wanted to call this syscall but couldn't" mechanism.

- Josh Triplett