[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48B441E1.5090304@gmail.com>
Date: Tue, 26 Aug 2008 19:48:17 +0200
From: Tejun Heo <htejun@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: Ingo Molnar <mingo@...e.hu>, Al Viro <viro@...IV.linux.org.uk>,
hch@...radead.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Eric Van Hensbergen <ericvh@...il.com>,
Ron Minnich <rminnich@...dia.gov>,
v9fs-developer@...ts.sourceforge.net, Takashi Iwai <tiwai@...e.de>
Subject: Re: [PATCH 2/2] poll: allow f_op->poll to sleep
(cc'ing Takashi Iwai)
Hello, Linus.
Linus Torvalds 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?
No big conceptual reason at all. I was trying to implement poll for
FUSE so that character device can be implemented in userspace such that
/dev/dsp can be routed to pulseaudio (or whatever) and for userland
filesystem, non-sleep poll just couldn't be made to work and there
didn't seem to be no big reason for poll not being able to sleep, so...
The OSS sound routing is probably a bit too late but the exclusion
between OSS and the modern sound system is still quite annoying and for
simple sound apps OSS interface is just much simpler as it's just normal
file IOs and fully contained in kernel (e.g. arch-um host sound support).
> If you worry about debuggability, then we could just add a
>
> preempt_enable();
> ..
> preempt_disable();
>
> around the poll calls (purely for catching errors) to get a big warning if
> somebody tries to call a sleepable function.
Yeap, that will be a nice debug option to have if this patch gets NACKed.
Thanks.
--
tejun
--
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/
Powered by blists - more mailing lists