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

[Evgeniy Polyakov]

On Mon, Aug 21, 2006 at 12:01:04PM +0100, Christoph Hellwig (hch@xxxxxxxxxxxxx) wrote:
> 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?

Sure, but if I say that it would sound like advertisement :)
Some inotify notifications (inode create/remove) are implemented already
in (dropped) FS notification patchset.

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