linux-kernel - Re: [patch 14/22] pollfs: pollable futex

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

Date:	Sun, 6 May 2007 13:18:47 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
cc:	Ulrich Drepper <drepper@...il.com>,
	Davi Arnaut <davi@...ent.com.br>,
	Eric Dumazet <dada1@...mosbay.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch 14/22] pollfs: pollable futex

On Sun, 6 May 2007, Andrew Morton wrote:

> On Sun, 6 May 2007 00:50:47 -0700 "Ulrich Drepper" <drepper@...il.com> wrote:
> 
> > > I really do not understand your point. You're too smart to not appreciate
> > > the beauty and the simmetry of objects that responds to a common interface
> > > (our files, win32 handles), and that fits our existing kernel infrastructure.
> > 
> > You're blinded by this symmetry.  Not everything that looks like a
> > good fit is a good idea.  This is one case.  Get over it, poll is not
> > powerful enough to serve as the unifying event mechanism.
> 
> What is your position on the timerfd/signalfd/etc patches?
> 
> Seems to me that if we were to have fancy new event-delivery machinery
> like kevent then the timerfd/signalfd work is heading in the other
> direction and ultimately would prove to have been unneeded?

Yes, of course. If we're heading to yet-another monolitic interface, we're 
heading with no valid reasons given if other than some handwaving. While 
there are quite a few (modularity, compatibilty, plus the other ones that 
came in my mind and that I explained in the way-too-many emails) to back a 
file-based approach.
Conversation with Uli, as often happen when arguing about software, got 
stuck. And since noone else seems interested in bringing valid points in 
one way or another, I'll leave the discussion as is, and I'll let you sort 
it out.



- Davide


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