On Tue, 4 Sep 2007, Michael Kerrisk wrote: > 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.
The fact that POSIX defined a certain API in a given way, does not automatically mean that every other API has to look exactly like that. POSIX has the tendency to bloat things up at times ;) > > 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. >From your patch: fs/compat.c | 34 ++++++++-- fs/timerfd.c | 147 +++++++++++++++++++++++++++++++++++++++-------- include/linux/compat.h | 3 include/linux/syscalls.h | 3 4 files changed, 153 insertions(+), 34 deletions(-) And the API definition becomes pretty messy. The other way is to add new system calls. 120+ lines of code more of new system calls wouldn't even be a problem in itself, if the added value was there. IMO, as I already said, the added value does not justify them. - Davide - 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/
