Re: [PATCH 2/2] poll: allow f_op->poll to sleep

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Tue, 26 Aug 2008, Tejun Heo wrote:
> > 
> > This patch converts poll/select to use custom wake up function and use
> > separate triggered variable to synchronize against wake up events.
> > The only added overhead is an extra function call during wake up and
> > negligible.
> 
> I don't really see the point.
> 
> poll() isn't allowed to sleep for many reasons. Some are technical. 
> But the most obvious one is that a sleeping "poll()" is totally 
> against the whole point of polling in the first place!
> 
> So is there some big conceptual reason to change how poll() has always 
> worked?

i think the point is to replace potentially fragile atomic code with 
less restricted 'potentially sleeping' code.

For example a GFP_KERNEL allocation will not sleep in 99% of the cases, 
and if it sleeps we are under such memory pressure that we dont really 
care all that much whether we happen to sleep in poll() or in the next 
userspace pagefault.

The whole ->poll() handler model would be less restricted. I dont think
that's a bad idea - all our atomic contexts suffer from programmability
restrictions, and people are trying to get away from them.

Plus it seems to enable FUSE some more as well - and FUSE has been 
spearheading a lot of filesystem development lately. FUSE is IMO the 
useful form of microkernels - a fast prototyping platform with a very 
friendly user-space programming and debugging interface. (and the fact 
that FUSE based filesystems can be packaged up and distributed a lot 
easier than kernel changes is an argument in favor of FUSE as well)

	Ingo