Messages in this thread | | | Date | Tue, 04 Sep 2007 22:49:32 +0200 | From | "Michael Kerrisk" <> | Subject | Re: [PATCH] Revised timerfd() interface |
| |
> > > The ABI change doesn't really matter, since timerfd() was broken in > > > 2.6.22 anyway. > > > > > > Both previous APIs provided the features I have described provide: > > > > > > * the ability to fetch the old timer value when applying > > > a new setting > > > > > > * the ability to non-destructively fetch the amount of time remaining > > > on a timer. > > > > > > This is clearly useful for timers -- but you have not explained why > > > you think this is not necessary for timerfd timers. > > > > <wakes up> > > > > I'd have thought that the existing stuff would be near-useless without > > the capabilities which you describe? > > Useless like it'd be a motorcycle w/out a cup-holder :) > Seriously, the ability to get the previous values from "something" could > have a meaning if this something is a shared global resource (like > signals > for example). In the timerfd case this makes little sense, since you can > create as many timerfd as you like and you do not need to share a single > one by changing/restoring the original context.
Davide,
As I think about this more, I see more problems with your argument. timerfd needs the ability to get and get-while-setting just as much as the earlier APIs. Consider a library that creates a timerfd file descriptor that is handed off to an application: that library may want to modify the timer settings without having to create a new file descriptor (the app mey not be able to be told about the new fd). Your argument just doesn't hold, AFAICS.
Cheers,
Michael -- Michael Kerrisk maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance? Grab the latest tarball at http://www.kernel.org/pub/linux/docs/manpages , read the HOWTOHELP file and grep the source files for 'FIXME'.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |