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

On Tue, 13 Sep 2016, Nicolas Pitre wrote: > On Fri, 9 Sep 2016, Thomas Gleixner wrote: > > You forgot CONFIG_TIMERFD > > Unless I'm mistaken, I don't see anything in timerfd.c that depends on > the (removed) POSIX timer code. What am I missing? Sorry, my memory tricked me. timerfd merily

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

On Tue, 13 Sep 2016, Nicolas Pitre wrote: > On Fri, 9 Sep 2016, Thomas Gleixner wrote: > > You forgot CONFIG_TIMERFD > > Unless I'm mistaken, I don't see anything in timerfd.c that depends on > the (removed) POSIX timer code. What am I missing? Sorry, my memory tricked me. timerfd merily

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

On Fri, 9 Sep 2016, Thomas Gleixner wrote: > On Thu, 8 Sep 2016, Nicolas Pitre 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

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

On Fri, 9 Sep 2016, Thomas Gleixner wrote: > On Thu, 8 Sep 2016, Nicolas Pitre 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

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

On Fri, 9 Sep 2016, Josh Triplett wrote: > On Fri, Sep 09, 2016 at 09:48:57AM +0200, Richard Cochran wrote: > > On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > > > Also given many other syscalls take clockids and the backing logic > > > isn't really getting removed (probably could

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

On Fri, 9 Sep 2016, Josh Triplett wrote: > On Fri, Sep 09, 2016 at 09:48:57AM +0200, Richard Cochran wrote: > > On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > > > Also given many other syscalls take clockids and the backing logic > > > isn't really getting removed (probably could

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

On Fri, 9 Sep 2016, Richard Cochran wrote: > On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > > 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

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

On Fri, 9 Sep 2016, Richard Cochran wrote: > On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > > 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

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

On Thu, 8 Sep 2016, Nicolas Pitre 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

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

On Thu, 8 Sep 2016, Nicolas Pitre 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

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

On Fri, Sep 09, 2016 at 09:48:57AM +0200, Richard Cochran wrote: > On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > > 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

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

On Fri, Sep 09, 2016 at 09:48:57AM +0200, Richard Cochran wrote: > On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > > 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

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

On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > 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

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

On Thu, Sep 08, 2016 at 02:19:24PM -0700, John Stultz wrote: > 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

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

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 wrote: > > > > Small embedded systems typically don't

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

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 wrote: > > > > Small embedded systems typically don't need them. This

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

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 wrote: > > > Small embedded systems typically don't need them. This removes about > > > 16KB from the kernel binary size on

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

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 wrote: > > > Small embedded systems typically don't need them. This removes about > > > 16KB from the kernel binary size on ARM when

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 wrote: > > Small embedded systems typically don't need them. This removes about > > 16KB from the kernel binary size on ARM when configured out. > > Corresponding

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

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

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

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

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

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

On Thu, Sep 8, 2016 at 2:05 PM, Nicolas Pitre 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

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

On Thu, Sep 8, 2016 at 2:05 PM, Nicolas Pitre 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