linux-kernel - Re: [patch 00/22] pollfs: filesystem abstraction for pollable objects

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:	Wed, 02 May 2007 14:47:58 -0300
From:	Davi Arnaut <davi@...ent.com.br>
To:	Davide Libenzi <davidel@...ilserver.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch 00/22] pollfs: filesystem abstraction for pollable objects

Davide Libenzi wrote:
> On Tue, 1 May 2007, Andrew Morton wrote:
>
>   
>> David, could you provide some feedback please?  The patches are stunningly
>> free of comments, but you used to do that to me pretty often so my sympathy
>> is limited ;)
>>     
>
> You bastard! :)
> Ok, from a brief look ...
>
> [general]
> The code adds an extra indirection over the already existing 
> file_operations, that IMO already sufficently abstract a file.
> The compat code, if I read it correctly, does not support files crossing 
> 32/64 bits boundaries (exec or SCM_RIGHTS).
>
>   

The compat code is not already finished, I plan to address compat
code on the next version.

> [timers]
> Returns a structure instead of a 32 bit counter (ala timerfd), and needs 
> extra compat code.
>   

Yes, but the compat code will be quite small.


> [signal]
> All the discussions that went on for signalfd has been lost. It pins the 
> task struct and it does not handle process detach signaling.
>   

No, I just went into a different direction.

> [aio]
> I prefer a signaling-only approach like the 20 lines patch I posted, and 
> use the standard AIO calls to fetch results. This code simply wraps AIO 
> calls. This is just my opinions of course, and others may disagree.
>   

The write()/read() wraps are just for the sake of completeness. The import
part is the poll().

> [futex]
> I intentionally stayed out of there after all the talks about futexfd 
> being killed due to the impossibility of getting an interface right (did 
> not follow the talk, so I can't tell the level of BS contained in the 
> previous statement). We also have a nice printk in there, with the first 
> kill-on deadline that ever made mainline :)
>
>   
Yes, i was more daring (or crazy). The plfutex is so simple, i don't
know why we can't get it right. It's just a _event_ (address/value).

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