On Mon, Aug 21, 2006 at 12:01:04PM +0100, Christoph Hellwig ([email protected]) 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
