linux-kernel - Re: [RFC] What are the goals for the architecture of an in-kernel IR system?

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: <4B139721.5030808@redhat.com>
Date:	Mon, 30 Nov 2009 07:57:53 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Jon Smirl <jonsmirl@...il.com>, Andy Walls <awalls@...ix.net>,
	Krzysztof Halasa <khc@...waw.pl>,
	Christoph Bartelmus <lirc@...telmus.de>,
	dmitry.torokhov@...il.com, j@...nau.net, jarod@...hat.com,
	jarod@...sonet.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	maximlevitsky@...il.com, stefanr@...6.in-berlin.de,
	superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR  system?

Hi Alan,

Alan Cox wrote:

> Does it really make sense to put big chunks of protocol decoding crap for
> an interface which runs at about 1 character per second on a good day
> into the kernel ? Does it really make sense ot move 50K of code from user
> context to kernel context where it must meet strict security
> requirements, be extensively audited and cannot be paged. For embedded
> users will also have to be highly modular so no unused bits are loaded.

The same logic would apply to mouse, keyboards and serial consoles. 
It is possible to move everything to userspace. 

However, there are some reassons for they to be in kernelspace:
	- you may need them during boot time;
	- they are mandatory to allow the users interaction;
	- you need low latency.

The same arguments apply to IR, especially on embedded devices: some devices,
like TVs, Set Top TV boxes and IPTV Set Top Boxes have IR as their primary
input device.

Also, as changing a digital TV or an IP TV channel requires to discard the current
MPEG stream and getting a newer one, and it requires a large time until you'll
be able to output something to the user, one of the needs is to handle IR keystrokes
(especially channel up/down) as fast as possible, to try to minimize the discomfort
of changing a channel.

Using an approach where you'll send a raw event to userspace, process there and return
back to kernel will increase the latency and can only be done after when loading
the SYSV runlevel stuff.

On the other hand, we already have IR decoding in-kernel. Most of the code are
at:
	drivers/media/common/ir-functions.c

But there are also some other decoders at bttv, saa7134 and cx88 drivers.

In the case of drivers/media stuff, there common case is that the drivers have
support for both space/pulse decoding and in-hardware decoding. On both cases,
the scancode is converted to a keystroke via evdev. IMHO, we shouldn't really
consider dropping those decoders from kernel.

Cheers,
Mauro. 
--
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/