Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 4 Mar 2014 13:53:03 -0800 | Subject | Re: [PATCH v4 5/6] timerfd: Add support for deferrable timers |
| |
On Tue, Mar 4, 2014 at 12:58 PM, Thomas Gleixner <tglx@linutronix.de> wrote: > On Tue, 25 Feb 2014, Andy Lutomirski wrote: >> On the other hand, if you added a fancier version of timerfd_settime >> that could explicitly set the slack value (or, equivalently, the >> earliest and latest allowable times), that could be quite useful. >> >> It's often bugged me that timer slack is per-process. > > That's a totally different issue. There is a world aside of timerfd > timers.
This is a patch to add deferrable support *to timerfd*. I'm asking why this is a useful feature to add. Some day (maybe soon -- systemd is doing something awful here) people will want choices of slack values other than the per-process value and infinity. Why not just do that and skip this intermediate API that will have to be supported forever?
I admit that I don't really understand the difference between hrtimers and the other kind of timer internally, but I don't see why this should have any effect at all of the userspace API. The kernel supports slack, slack is strictly more useful than "deferrable", so let's just expose it properly to userspace.
--Andy
| |