[<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
 
