linux-kernel - Re: [patch 6/9] signalfd/timerfd v1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0703092323370.28135@alien.or.mcafeemobile.com>
Date:	Fri, 9 Mar 2007 23:36:57 -0800 (PST)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Nicholas Miell <nmiell@...cast.net>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch 6/9] signalfd/timerfd v1 - timerfd core ...

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