Re: [PATCH 29/49] vcs: add poll/fasync support
From: Kay Sievers
Date: Tue Nov 09 2010 - 20:42:40 EST
On Wed, Nov 10, 2010 at 02:26, Nicolas Pitre
<nicolas.pitre@xxxxxxxxxxxxx> wrote:
> On Wed, 10 Nov 2010, Kay Sievers wrote:
>
>> On Fri, Oct 22, 2010 at 20:21, Greg Kroah-Hartman <gregkh@xxxxxxx> wrote:
>> > From: Nicolas Pitre <nico@xxxxxxxxxxx>
>> >
>> > The /dev/vcs* devices are used, amongst other things, by accessibility
>> > applications such as BRLTTY to display the screen content onto refreshable
>> > braille displays. ÂCurrently this is performed by constantly reading from
>> > /dev/vcsa0 whether or not the screen content has changed. ÂGiven the
>> > default braille refresh rate of 25 times per second, this easily qualifies
>> > as the biggest source of wake-up events preventing laptops from entering
>> > deeper power saving states.
>> >
>> > To avoid this periodic polling, let's add support for select()/poll() and
>> > SIGIO with the /dev/vcs* devices. ÂThe implemented semantic is to report
>> > data availability whenever the corresponding vt has seen some update after
>> > the last read() operation. ÂThe application still has to lseek() back
>> > as usual in order to read() the new data.
>>
>> Shouldn't it raise POLLPRI/POLLERR then, when it's not about new data
>> to read? We do this for several files in the kernel where we just want
>> to wakup someone, but the pretty well-defined semantics of poll()
>> don't apply.
>
> Hmmm... ÂMaybe POLLPRI, but POLLERR makes no sense.
I have no opinion about that, but it's what others do:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=31b07093c44a7a442394d44423e21d783f5523b8
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4508a7a734b111b8b7e39986237d84acb1168dd0
The POLLIN should definitely go, it's POSIX defined. What we do here
is more like an error that wakes up than a stream data to read. :)
Kay
--
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/