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-prev] [day] [month] [year] [list]

Message-ID: <20060821112609.GD8608@2ka.mipt.ru>
Date:	Mon, 21 Aug 2006 15:26:10 +0400
From:	Evgeniy Polyakov <johnpol@....mipt.ru>
To:	Christoph Hellwig <hch@...radead.org>
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 Mon, Aug 21, 2006 at 12:01:04PM +0100, Christoph Hellwig (hch@...radead.org) 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/