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

Davide Libenzi
2007-03-10T07:37:01Z

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