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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
