Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...

[Davide Libenzi]

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