lkml.org 
[lkml]   [2008]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] poll: allow f_op->poll to sleep

* 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


\
 
 \ /
  Last update: 2008-08-26 22:25    [W:0.987 / U:0.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site