[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061103091645.GA935@2ka.mipt.ru>
Date: Fri, 3 Nov 2006 12:16:45 +0300
From: Evgeniy Polyakov <johnpol@....mipt.ru>
To: zhou drangon <drangon.mail@...il.com>
Cc: Eric Dumazet <dada1@...mosbay.com>, linux-kernel@...r.kernel.org,
Oleg Verych <olecom@...wer.upol.cz>,
Pavel Machek <pavel@....cz>,
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>,
drangon.zhou@...il.com
Subject: Re: [take22 0/4] kevent: Generic event handling mechanism.
On Fri, Nov 03, 2006 at 10:42:04AM +0800, zhou drangon (drangon.mail@...il.com) wrote:
> As for the VFS system, when we introduce the AIO machinism, we add aio_read,
> aio_write, etc... to file ops, and then we make the read, write op to
> call aio_read,
> aio_write, so that we only remain one implement in kernel.
> Can we do event machinism the same way?
> when kevent is robust enough, can we implement epoll/select/io_submit etc...
> base on kevent ??
> In this way, we can simplified the kernel, and epoll can gain
> improvement from kevent.
There is AIO implementaion on top of kevent, although it was confirmed
that it has a good design, except minor API layering changes, it was
postponed for a while.
--
Evgeniy Polyakov
-
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