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]

Message-ID: <Pine.LNX.4.64.0705061034230.25105@alien.or.mcafeemobile.com>
Date:	Sun, 6 May 2007 12:47:21 -0700 (PDT)
From:	Davide Libenzi <davidel@...ilserver.org>
To:	Ulrich Drepper <drepper@...il.com>
cc:	Davi Arnaut <davi@...ent.com.br>,
	Eric Dumazet <dada1@...mosbay.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	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, Ulrich Drepper wrote:

> On 5/5/07, Davide Libenzi <davidel@...ilserver.org> wrote:
> > But we have our own *sane* version of WaitForMultipleObjects, and it's
> > called poll(2).
> 
> No, we don't.  Don't start all over again.  The interface of poll it
> to primitive.  See the kevent code, each record is, IIRC, 16 bytes in
> size to return more data.  For poll you only have bits.

Yes, event bits plus opaque token are enough for most of it. Then you use 
POSIX read/write to fetch/store the data. All the files (sockets, pipes, ...)
works this way. Signals you fetch a siginfo-like structure, through POSIX 
read. Timers, you fetch a counter, through POSIX read. AIO, you use the 
native AIO API (that I'd prefer, or you can choose to have a POSIX read 
too). All these through isolated POSIX read semantics.
Now let's see how it'd look with a monolitic kevent-like interface. You'll 
have a mosnter-union ala siginfo_t, with multiple nested structures, and 
every time you need to extend it, you'll go through pain. Come on, that's 
beyond ugly. With a file-like interface, each new addition comes to a 
seaparate isolated interface, with separate POSIX read/write ABI.
Do you realise that to justify your all new bulk interface, 
you had to pull out of the hat a Windows WaitForMultipleObjects?
Please drop the BS. I made you a full list of things that are readily and 
POSIX-friendly handled/signaled with file-like interfaces.
Any sockets, pipes, all devices, signals, timers, AIO, and I'm probably 
forgetting something.
You pulled "it's slow". False.
You pulled "it's memory expensive". It's not.
So far, I did not hear a single valid reason to go with a new, monolitic 
interface. WaitForMultipleObjects? Please ...

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