[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1190481002.4035.51.camel@chaos>
Date: Sat, 22 Sep 2007 19:10:02 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Michael Kerrisk <mtk-manpages@....net>
Cc: Davide Libenzi <davidel@...ilserver.org>,
Ulrich Drepper <drepper@...hat.com>, geoff@...are.org.uk,
lkml <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
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>,
David Härdeman <david@...deman.nu>
Subject: Re: RFC: A revised timerfd API
Michael,
On Sat, 2007-09-22 at 15:12 +0200, Michael Kerrisk wrote:
> Davide, Andrew, Linus, et al.
>
> At the start of this thread
> (http://thread.gmane.org/gmane.linux.kernel/581115 ), I proposed 4
> alternatives to Davide's original timerfd API. Based on the feedback in
> that thread (and one or two earlier comments):
>
> Let's dismiss option (a), since it is an unlovely multiplexing interface.
>
> Option (b) seems a viable. The most notable concern was from Thomas
> Gleixner, that we might end up duplicating code from the POSIX timers API
> within the timerfd API -- some eventual refactoring might mitigate this
> problem.
It should be possible to use the timerfd syscalls as wrappers for the
posix timer implementation and add the discussed SIGEV_TIMERFD only
internally in the kernel to signal the posix timer code new delivery
mechanism.
tglx
-
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