Re: [take9 2/2] kevent: poll/select() notifications. Timer notifications.

[Christoph Hellwig <hch@infradead.org>]

On Fri, Aug 18, 2006 at 02:59:34PM +0400, Evgeniy Polyakov wrote:
> > 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 :)

You mention a lot of implementation details that absoultely shouldn't
matter to the userspace interface.

I might not have explained enough what the point behind all this is, so
I'll try to explain it again:

 - the fate of aio, inotify, epoll, etc shows we badly need a generic
   event mechnism that unifies event based interfaces of various subsystem.
   Only having a single mechanisms allows things like unified event loops
   and gives application progreammers the chance to learn that one interface
   for real and get it right.
 - kevent looks like the right way to do this.  but to show it can really
   archive this it needs to show it can do the things the existing event
   systems can do at least as good.  reimplementing their user interfaces
   ontop of kevent is the best (or maybe only) way to show that.
   epoll is probably the easiest of the ones we have, so I'd suggest starting
   with it.  inotify will be a lot harder, but we'll need that aswell.
   the kevent inode hooks you had in your earlier patches will never ever
   get in.

Was this clear enough?