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]

Message-ID: <4638DD76.7090904@haxent.com.br>
Date:	Wed, 02 May 2007 15:50:30 -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 Wed, 2 May 2007, Davi Arnaut wrote:
>
>   
>> 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.
>>     
>
> How? Compat on sys_read/sys_write?
>
>   
Yes. More on that later.
>>> [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.
>>     
>
> Why would that be even justified?
>
>
>   
Because the developer may need it.
>>> [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.
>>     
>
> I'd say wrong, because signalfd addressed valid concerns of quite a few 
> ppl.
>
>   
So in this case I may borrow some signalfd code :-) I really like the
signalfd approach, but IMHO the code is quite ugly and duplicates
a lot of hairy code.

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