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]

Date:	Mon, 30 Nov 2009 09:56:42 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Andy Walls <awalls@...ix.net>
CC:	Ray Lee <ray-lk@...rabbit.org>,
	Maxim Levitsky <maximlevitsky@...il.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jon Smirl <jonsmirl@...il.com>,
	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,
	stefanr@...6.in-berlin.de, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR  system?

Andy Walls wrote:
> On Sun, 2009-11-29 at 09:49 -0800, Ray Lee wrote:
>> On Sun, Nov 29, 2009 at 9:28 AM, Maxim Levitsky <maximlevitsky@...il.com> wrote:
>>> This has zero advantages besides good developer feeling that "My system
>>> has one less daemon..."
>> Surely it's clear that having an unnecessary daemon is introducing
>> another point of failure?
> 
> A failure in a userspace IR daemon is worst case loss of IR
> functionality.
> 
> A failure in kernel space can oops or panic the machine.

If IR is the only interface between the user and the system (like in a TV
or a Set Top Box), both will give you the same practical result: the system
will be broken, if you got a crash at the IR driver.

> Userspace is much more flexible.

Why? The flexibility about the same on both kernelspace and userspace,
except for the boot time.

A kernelspace input device driver can start working since boot time.
On the other hand, an userspace device driver will be available only 
after mounting the filesystems and starting the deamons 
(e. g. after running inittab). 

So, you cannot catch a key that would be affecting the boot 
(for example to ask the kernel to run a different runlevel or entering
on some administrative mode).

After the boot, and providing that the kernel has the proper
API's, a pure userspace driver can behave just like a kernelspace
driver and vice-versa. The only difference may be in terms of device
transfer rate (not relevant for input devices) and latency.

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/