linux-kernel - Re: [PATCH 29/49] vcs: add poll/fasync support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <AANLkTinfLT0WYDHek8+QjYKfGC0rtJ3ZFhoZj2fD8-Ri@mail.gmail.com>
Date:	Wed, 10 Nov 2010 02:42:10 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Nicolas Pitre <nicolas.pitre@...onical.com>
Cc:	Greg Kroah-Hartman <gregkh@...e.de>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 29/49] vcs: add poll/fasync support

On Wed, Nov 10, 2010 at 02:26, Nicolas Pitre
<nicolas.pitre@...onical.com> wrote:
> On Wed, 10 Nov 2010, Kay Sievers wrote:
>
>> On Fri, Oct 22, 2010 at 20:21, Greg Kroah-Hartman <gregkh@...e.de> wrote:
>> > From: Nicolas Pitre <nico@...xnic.net>
>> >
>> > 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/