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

[Davi Arnaut]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/