[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <458A64E5.4050703@garzik.org>
Date: Thu, 21 Dec 2006 05:41:41 -0500
From: Jeff Garzik <jeff@...zik.org>
To: Evgeniy Polyakov <johnpol@....mipt.ru>
CC: linux-kernel@...r.kernel.org, David Miller <davem@...emloft.net>,
Ulrich Drepper <drepper@...hat.com>,
Andrew Morton <akpm@...l.org>, netdev <netdev@...r.kernel.org>,
Zach Brown <zach.brown@...cle.com>,
Christoph Hellwig <hch@...radead.org>,
Chase Venters <chase.venters@...entec.com>,
Johann Borck <johann.borck@...sedata.com>
Subject: Re: [take28-resend_1->0 0/8] kevent: Generic event handling mechanism.
Evgeniy Polyakov wrote:
> On Thu, Dec 21, 2006 at 12:14:17PM +0300, Evgeniy Polyakov (johnpol@....mipt.ru) wrote:
>> Generic event handling mechanism.
>>
>> Kevent is a generic subsytem which allows to handle event notifications.
>> It supports both level and edge triggered events. It is similar to
>> poll/epoll in some cases, but it is more scalable, it is faster and
>> allows to work with essentially eny kind of events.
>>
>> Events are provided into kernel through control syscall and can be read
>> back through ring buffer or using usual syscalls.
>> Kevent update (i.e. readiness switching) happens directly from internals
>> of the appropriate state machine of the underlying subsytem (like
>> network, filesystem, timer or any other).
>>
>> Homepage:
>> http://tservice.net.ru/~s0mbre/old/?section=projects&item=kevent
>>
>> Documentation page:
>> http://linux-net.osdl.org/index.php/Kevent
>>
>> Consider for inclusion.
>
> Due to this stall kevent inclusion into lighttpd CVS tree is postponed.
>
> The last version will be released saturday or sunday, and looking into
> overhelming flow of feedback comments on this feature, project will not
> be released to linux-kernel@, after this I will
> complete netchannels support and start kevent based AIO project - mostly
> network AIO with new design, which is based on set of entities, which
> can describe set of tasks which should be performed
> asynchronously (from user point of view, although read and write
> obviously must be done after open and before close), for example syscall
kevent is being considered for inclusion, but there is no need to get
impatient. Once kevent code stops getting revised rapidly, Andrew
Morton can pick it up for -mm, for wide dissemination, testing and
review. After that phase, it can be pushed to mainline.
The feeling I get from other kernel hackers is that you are demanding
inclusion "now! now! now!" rather than giving all stakeholders a chance
to give input, and let your design sink into the collective brain.
This isn't just an optional feature but a key new addition to the
kernel. So we should intentionally take more time and consideration
than normal. We don't want to go back and have to change fundamental
kevent details due to design flaws, we want to get it right.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists