Messages in this thread | | | Date | Tue, 04 Sep 2007 17:39:40 +0200 | From | "Michael Kerrisk" <> | Subject | Re: [PATCH] Revised timerfd() interface |
| |
Hi Davide,
> > <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.
However, one can have multipe POSIX timers, just as you can have multiple timerfd timers; nevertheless POSIX timers provide the get and get-while-setting functionality.
> On top of that, the cup-holder addition would cost in terms of API > clarity
I agree my proposed API is not as clean as it could be, that's why I would favour:
> (or in terms of two additional system calls in the other case),
Or better still, have timerfd() integrated with POSIX tiemrs (if this is feasible). This givesus a simple API, exactly one new syscall, and all of the functionality of the existing POSIX timers API.
> and in terms of kernel code footprint.
Not sure what your concern is here. The total amount of new code for all of these options is pretty small.
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/
| |