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]
Message-ID: <Pine.LNX.4.64.0705061309410.25331@alien.or.mcafeemobile.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ