lkml.org 
[lkml]   [2006]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [take9 2/2] kevent: poll/select() notifications. Timer notifications.
On Fri, Aug 18, 2006 at 11:41:20AM +0100, Christoph Hellwig (hch@infradead.org) wrote:
> On Wed, Aug 16, 2006 at 05:40:32PM +0400, Evgeniy Polyakov wrote:
> > > What speaks against a patch the recplaces the epoll core by something that
> > > build on kevent while still supporting the epoll interface as a compatibility
> > > shim?
> >
> > There is no problem from my side, but epoll and kevent_poll differs on
> > some aspects, so it can be better to not replace them for a while.
>
> Please explain the differences and why they are important. We really
> shouldn't keep on adding code without beeing able to replace older bits.
> If there's a really good reason we can keep things separate, but
>
> "epoll and kevent_poll differs on some aspects"
>
> is not one :)

kevent_poll uses hash table (actually it is kevent that uses table),
locking is simpler and part of it is hidden in kevent core.
Actually kevent_poll is just a container allocator for poll wait queue.
So epoll does not differ (except hash/tree and locking,
which is based on locks for pathes which are shared in kevent with those
ones which can be called from irq/bh context) from kevent + kevent_poll.
And since kevent_poll can be not selected while epoll is always there
(until embedded config is turned on), I recommend to have them both.
Or always turn kevent on :)

--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-08-18 13:17    [W:0.136 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site