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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 21 Aug 2006 12:01:04 +0100
From:	Christoph Hellwig <hch@...radead.org>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	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>, tglx@...utronix.de
Subject: Re: [take9 2/2] kevent: poll/select() notifications. Timer notifications.

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?
-
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/