[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALAqxLXmbDgcc1oVZezzY=oRV4johPgxFNpWBBfO4Hk9tZiBJg@mail.gmail.com>
Date: Thu, 8 Sep 2016 14:19:24 -0700
From: John Stultz <john.stultz@...aro.org>
To: Nicolas Pitre <nico@...xnic.net>,
Josh Triplett <josh@...htriplett.org>
Cc: 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 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.
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.
thanks
-john
Powered by blists - more mailing lists