[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20070922233744.GA2218@hardeman.nu>
Date: Sun, 23 Sep 2007 01:37:44 +0200
From: David Härdeman <david@...deman.nu>
To: Michael Kerrisk <mtk.linux.lists@...il.com>
Cc: Bernd Eckenfels <ecki@...a.inka.de>, linux-kernel@...r.kernel.org,
Ulrich Drepper <drepper@...hat.com>, geoff@...are.org.uk,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Christoph Hellwig <hch@....de>,
Jonathan Corbet <corbet@....net>,
Randy Dunlap <rdunlap@...otime.net>, vda.linux@...glemail.com,
Linus Torvalds <torvalds@...ux-foundation.org>,
Lee Schermerhorn <Lee.Schermerhorn@...com>,
mtk-manpages@....net
Subject: Re: RFC: A revised timerfd API
On Sat, Sep 22, 2007 at 06:07:14PM +0200, Michael Kerrisk wrote:
>On 9/22/07, Bernd Eckenfels <ecki@...a.inka.de> wrote:
>> In article <46F514C9.5010208@....net> you wrote:
>> > 1. This design stretches the POSIX timers API in strange
>> > ways.
>>
>> Maybe it is possible to reimplement the POSIX API in usermode using the
>> kernel's FD implementation?
>
>It's a clever idea... Without thinking on it too long, I'm not sure
>whether or not there might be some details which would make this
>difficult.
It seems to be a dangerous idea. It has the potential of breaking
userspace applications that rely on POSIX timers not creating fd's.
Image code like this:
/* Close stdin, stdout, stderr */
close(0);
close(1);
close(2);
/* Oh, a timer would be nice */
timer_create(x, y, z);
/* Create new stdin, stdout, stderr */
fd = open("/dev/null", flags);
dup(fd);
dup(fd);
Unless timer_create does some magic to avoid using the lowest available
fd, this would suddenly break as the timerfd would be fd 0.
--
David Härdeman
-
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/
Powered by blists - more mailing lists