On Fri, 9 Mar 2007, Nicholas Miell wrote: > On Fri, 2007-03-09 at 22:53 -0800, Davide Libenzi wrote: > > On Fri, 9 Mar 2007, Nicholas Miell wrote: > > > > > > So extend the existing POSIX timer API to deliver expiry events via a > > > fd. > > > > It'll be out of standard as timerfd is, w/out code savings. Look at the > > code and tell me what could be saved. Prolly the ten lines of the timer > > callback. Lines that you'll have to drop inside the current posix timer > > layer. Better leave standards alone, especially like in this case, when > > the savings are not there. > > > > OK, here's a more formal listing of my objections to the introduction of > timerfd in this form: > > A) It is a new general-purpose ABI intended for wide-scale usage, and > thus must be maintained forever.
Yup > B) It is less functional than the existing ABIs -- modulo their > "delivery via signals only" limitation, which can be corrected (and has > been already in other operating systems). Less functional? Please, do tell me ... > C) Being an entirely new creation that completely ignores past work in > this area, it has no hope of ever getting into POSIX. > > which means > > D) At some point in time, Linux is going to get the POSIX version (in > whatever form it takes), making this new ABI useless dead weight (see > point A). Adding parameters/fields to a standard is going to create even more confusion than a new *single* function. And the code to cross-link the timerfd and the current posix timers is going to end up in being more complex than the current one. - 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/
