* [RFC/PATCH] posix-timers: make them configurable @ 2016-09-08 21:05 Nicolas Pitre 2016-09-08 21:19 ` John Stultz 2016-09-09 13:39 ` Thomas Gleixner 0 siblings, 2 replies; 12+ messages in thread From: Nicolas Pitre @ 2016-09-08 21:05 UTC (permalink / raw) To: Thomas Gleixner, John Stultz; +Cc: linux-kernel 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@linaro.org> diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig index ee3de3421f..00e6098e9a 100644 --- a/drivers/ptp/Kconfig +++ b/drivers/ptp/Kconfig @@ -6,7 +6,7 @@ menu "PTP clock support" config PTP_1588_CLOCK tristate "PTP clock support" - depends on NET + depends on NET && POSIX_TIMERS select PPS select NET_PTP_CLASSIFY help diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig index 62824f2fe4..b055aa1b6b 100644 --- a/kernel/time/Kconfig +++ b/kernel/time/Kconfig @@ -195,3 +195,13 @@ config HIGH_RES_TIMERS endmenu endif + +config POSIX_TIMERS + bool "Posix Clocks & timers" if EMBEDDED + default y + help + This includes native support for POSIX timers into the kernel. + Small embedded systems may have no use for them and therefore they + can be configured out to reduce the size of the kernel image. + If unsure say y. + diff --git a/kernel/time/Makefile b/kernel/time/Makefile index 49eca0beed..fc26c308f5 100644 --- a/kernel/time/Makefile +++ b/kernel/time/Makefile @@ -1,6 +1,12 @@ -obj-y += time.o timer.o hrtimer.o itimer.o posix-timers.o posix-cpu-timers.o +obj-y += time.o timer.o hrtimer.o itimer.o obj-y += timekeeping.o ntp.o clocksource.o jiffies.o timer_list.o -obj-y += timeconv.o timecounter.o posix-clock.o alarmtimer.o +obj-y += timeconv.o timecounter.o alarmtimer.o + +ifeq ($(CONFIG_POSIX_TIMERS),y) + obj-y += posix-timers.o posix-cpu-timers.o posix-clock.o +else + obj-y += posix-stubs.o +endif obj-$(CONFIG_GENERIC_CLOCKEVENTS) += clockevents.o tick-common.o ifeq ($(CONFIG_GENERIC_CLOCKEVENTS_BROADCAST),y) diff --git a/kernel/time/posix-stubs.c b/kernel/time/posix-stubs.c new file mode 100644 index 0000000000..879f37f6f3 --- /dev/null +++ b/kernel/time/posix-stubs.c @@ -0,0 +1,82 @@ +/* + * Dummy stubs used when CONFIG_POSIX_TIMERS=n + * + * Created by: Nicolas Pitre, July 2016 + * Copyright: (C) 2016 Linaro Limited + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include <linux/linkage.h> +#include <linux/kernel.h> +#include <linux/random.h> +#include <linux/errno.h> +#include <linux/posix-timers.h> + +asmlinkage long sys_ni_posix_timers(void) +{ + pr_err_once("process %d (%s) attempted a POSIX timer syscall " + "while CONFIG_POSIX_TIMERS is not set\n", + current->pid, current->comm); + return -ENOSYS; +} + +#define SYS_NI(name) SYSCALL_ALIAS(sys_##name, sys_ni_posix_timers) + +SYS_NI(timer_create); +SYS_NI(timer_gettime); +SYS_NI(timer_getoverrun); +SYS_NI(timer_settime); +SYS_NI(timer_delete); +SYS_NI(clock_settime); +SYS_NI(clock_gettime); +SYS_NI(clock_adjtime); +SYS_NI(clock_getres); +SYS_NI(clock_nanosleep); + +void do_schedule_next_timer(struct siginfo *info) +{ +} + +void exit_itimers(struct signal_struct *sig) +{ +} + +void posix_timers_register_clock(const clockid_t clock_id, + struct k_clock *new_clock) +{ +} + +int posix_timer_event(struct k_itimer *timr, int si_private) +{ + return 0; +} + +void run_posix_cpu_timers(struct task_struct *tsk) +{ +} + +void posix_cpu_timers_exit(struct task_struct *tsk) +{ + add_device_randomness((const void*) &tsk->se.sum_exec_runtime, + sizeof(unsigned long long)); +} + +void posix_cpu_timers_exit_group(struct task_struct *tsk) +{ +} + +void set_process_cpu_timer(struct task_struct *tsk, unsigned int clock_idx, + cputime_t *newval, cputime_t *oldval) +{ +} + +void update_rlimit_cpu(struct task_struct *task, unsigned long rlim_new) +{ +} + +void thread_group_cputimer(struct task_struct *tsk, struct task_cputime *times) +{ +} ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [RFC/PATCH] posix-timers: make them configurable 2016-09-08 21:05 [RFC/PATCH] posix-timers: make them configurable Nicolas Pitre @ 2016-09-08 21:19 ` John Stultz 2016-09-08 21:48 ` Josh Triplett ` (2 more replies) 2016-09-09 13:39 ` Thomas Gleixner 1 sibling, 3 replies; 12+ messages in thread From: John Stultz @ 2016-09-08 21:19 UTC (permalink / raw) To: Nicolas Pitre, Josh Triplett; +Cc: Thomas Gleixner, lkml, Richard Cochran On Thu, Sep 8, 2016 at 2:05 PM, Nicolas Pitre <nico@fluxnic.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@linaro.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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC/PATCH] posix-timers: make them configurable 2016-09-08 21:19 ` John Stultz @ 2016-09-08 21:48 ` Josh Triplett [not found] ` <i7B1bN3EzSJWci7B2bJXya@videotron.ca> 2016-09-09 7:48 ` Richard Cochran 2 siblings, 0 replies; 12+ messages in thread From: Josh Triplett @ 2016-09-08 21:48 UTC (permalink / raw) To: John Stultz; +Cc: Nicolas Pitre, Thomas Gleixner, lkml, Richard Cochran 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@fluxnic.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@linaro.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. 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. > 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. 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. (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. 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. This infrastructure would itself take up space, and wouldn't make any sense without CONFIG_PRINTK, hence making it optional. But as a debugging mechanism when working on shrinking a kernel for a target application, it seems quite useful. (The only caveat: a message wouldn't always indicate a problem, since an application may handle ENOSYS.) ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <i7B1bN3EzSJWci7B2bJXya@videotron.ca>]
* Re: [RFC/PATCH] posix-timers: make them configurable [not found] ` <i7B1bN3EzSJWci7B2bJXya@videotron.ca> @ 2016-09-08 23:56 ` Nicolas Pitre 2016-09-09 0:37 ` Josh Triplett 0 siblings, 1 reply; 12+ messages in thread From: Nicolas Pitre @ 2016-09-08 23:56 UTC (permalink / raw) To: Josh Triplett; +Cc: John Stultz, Thomas Gleixner, lkml, Richard Cochran 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@fluxnic.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@linaro.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. > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC/PATCH] posix-timers: make them configurable 2016-09-08 23:56 ` Nicolas Pitre @ 2016-09-09 0:37 ` Josh Triplett 0 siblings, 0 replies; 12+ messages in thread From: Josh Triplett @ 2016-09-09 0:37 UTC (permalink / raw) To: Nicolas Pitre; +Cc: John Stultz, Thomas Gleixner, lkml, Richard Cochran 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@fluxnic.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@linaro.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. > > > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC/PATCH] posix-timers: make them configurable 2016-09-08 21:19 ` John Stultz 2016-09-08 21:48 ` Josh Triplett [not found] ` <i7B1bN3EzSJWci7B2bJXya@videotron.ca> @ 2016-09-09 7:48 ` Richard Cochran 2016-09-09 8:00 ` Josh Triplett 2016-09-09 13:46 ` Thomas Gleixner 2 siblings, 2 replies; 12+ messages in thread From: Richard Cochran @ 2016-09-09 7:48 UTC (permalink / raw) To: John Stultz; +Cc: Nicolas Pitre, Josh Triplett, Thomas Gleixner, lkml 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 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 want to support tinification, but I also doubt the utility of removing clock_gettime() and clock_nanosleep(). I can't imagine ever building a user space without those. In fact, thinking about IoT, having good time is critical, and so these are the *last* functions I would remove when downsizing. Thanks, Richard ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC/PATCH] posix-timers: make them configurable 2016-09-09 7:48 ` Richard Cochran @ 2016-09-09 8:00 ` Josh Triplett 2016-09-09 13:47 ` Thomas Gleixner 2016-09-09 13:46 ` Thomas Gleixner 1 sibling, 1 reply; 12+ messages in thread From: Josh Triplett @ 2016-09-09 8:00 UTC (permalink / raw) To: Richard Cochran; +Cc: John Stultz, Nicolas Pitre, Thomas Gleixner, lkml 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 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 want to support tinification, but I also doubt the utility of > removing clock_gettime() and clock_nanosleep(). I can't imagine ever > building a user space without those. In fact, thinking about IoT, > having good time is critical, and so these are the *last* functions I > would remove when downsizing. 1) If you already have another function providing time and don't need two. 2) If you run an entirely event-driven loop and don't sleep. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC/PATCH] posix-timers: make them configurable 2016-09-09 8:00 ` Josh Triplett @ 2016-09-09 13:47 ` Thomas Gleixner 0 siblings, 0 replies; 12+ messages in thread From: Thomas Gleixner @ 2016-09-09 13:47 UTC (permalink / raw) To: Josh Triplett; +Cc: Richard Cochran, John Stultz, Nicolas Pitre, lkml 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 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 want to support tinification, but I also doubt the utility of > > removing clock_gettime() and clock_nanosleep(). I can't imagine ever > > building a user space without those. In fact, thinking about IoT, > > having good time is critical, and so these are the *last* functions I > > would remove when downsizing. > > 1) If you already have another function providing time and don't need two. Agreed. > 2) If you run an entirely event-driven loop and don't sleep. I hope you wanted to say: and don't use *nanosleep() :) Otherwise you'd have a full busy polling event loop which I doubt is desirable ... Thanks, tglx ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC/PATCH] posix-timers: make them configurable 2016-09-09 7:48 ` Richard Cochran 2016-09-09 8:00 ` Josh Triplett @ 2016-09-09 13:46 ` Thomas Gleixner 1 sibling, 0 replies; 12+ messages in thread From: Thomas Gleixner @ 2016-09-09 13:46 UTC (permalink / raw) To: Richard Cochran; +Cc: John Stultz, Nicolas Pitre, Josh Triplett, lkml 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 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 want to support tinification, but I also doubt the utility of > removing clock_gettime() and clock_nanosleep(). I can't imagine ever > building a user space without those. In fact, thinking about IoT, > having good time is critical, and so these are the *last* functions I > would remove when downsizing. gettimeofday() gives you microsecond resolution which is good enough for 99.9% of all problems. The only real downside is removing clock_nanosleep() because nanosleep() does not give you the ability to schedule timers on absolute time. Thanks, tglx ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC/PATCH] posix-timers: make them configurable 2016-09-08 21:05 [RFC/PATCH] posix-timers: make them configurable Nicolas Pitre 2016-09-08 21:19 ` John Stultz @ 2016-09-09 13:39 ` Thomas Gleixner 2016-09-13 20:57 ` Nicolas Pitre 1 sibling, 1 reply; 12+ messages in thread From: Thomas Gleixner @ 2016-09-09 13:39 UTC (permalink / raw) To: Nicolas Pitre; +Cc: John Stultz, linux-kernel 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 clue if they were > disabled without proper consideration. > > Signed-off-by: Nicolas Pitre <nico@linaro.org> > > diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig > index ee3de3421f..00e6098e9a 100644 > --- a/drivers/ptp/Kconfig > +++ b/drivers/ptp/Kconfig > @@ -6,7 +6,7 @@ menu "PTP clock support" > > config PTP_1588_CLOCK > tristate "PTP clock support" > - depends on NET > + depends on NET && POSIX_TIMERS > select PPS > select NET_PTP_CLASSIFY > help You forgot CONFIG_TIMERFD .... > +void do_schedule_next_timer(struct siginfo *info) > +{ > +} .... > +void thread_group_cputimer(struct task_struct *tsk, struct task_cputime *times) > +{ > +} You should make them static inlines in the headers so they get compiled out completely. Thanks, tglx ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC/PATCH] posix-timers: make them configurable 2016-09-09 13:39 ` Thomas Gleixner @ 2016-09-13 20:57 ` Nicolas Pitre 2016-09-14 9:47 ` Thomas Gleixner 0 siblings, 1 reply; 12+ messages in thread From: Nicolas Pitre @ 2016-09-13 20:57 UTC (permalink / raw) To: Thomas Gleixner; +Cc: John Stultz, linux-kernel 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 > > use those syscalls which should be enough of a clue if they were > > disabled without proper consideration. > > > > Signed-off-by: Nicolas Pitre <nico@linaro.org> > > > > diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig > > index ee3de3421f..00e6098e9a 100644 > > --- a/drivers/ptp/Kconfig > > +++ b/drivers/ptp/Kconfig > > @@ -6,7 +6,7 @@ menu "PTP clock support" > > > > config PTP_1588_CLOCK > > tristate "PTP clock support" > > - depends on NET > > + depends on NET && POSIX_TIMERS > > select PPS > > select NET_PTP_CLASSIFY > > help > > 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? Nicolas ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC/PATCH] posix-timers: make them configurable 2016-09-13 20:57 ` Nicolas Pitre @ 2016-09-14 9:47 ` Thomas Gleixner 0 siblings, 0 replies; 12+ messages in thread From: Thomas Gleixner @ 2016-09-14 9:47 UTC (permalink / raw) To: Nicolas Pitre; +Cc: John Stultz, linux-kernel 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 uses the posix timer clock ids but nothing from posix-timer.c. alarmtimer is a different story. Thanks, tglx ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-09-14 9:50 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-09-08 21:05 [RFC/PATCH] posix-timers: make them configurable Nicolas Pitre 2016-09-08 21:19 ` John Stultz 2016-09-08 21:48 ` Josh Triplett [not found] ` <i7B1bN3EzSJWci7B2bJXya@videotron.ca> 2016-09-08 23:56 ` Nicolas Pitre 2016-09-09 0:37 ` Josh Triplett 2016-09-09 7:48 ` Richard Cochran 2016-09-09 8:00 ` Josh Triplett 2016-09-09 13:47 ` Thomas Gleixner 2016-09-09 13:46 ` Thomas Gleixner 2016-09-09 13:39 ` Thomas Gleixner 2016-09-13 20:57 ` Nicolas Pitre 2016-09-14 9:47 ` Thomas Gleixner
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.