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: <4B140200.9020503@redhat.com>
Date:	Mon, 30 Nov 2009 15:33:52 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	kevin granade <kevin.granade@...il.com>
CC:	Andy Walls <awalls@...ix.net>, 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?

kevin granade wrote:
> On Mon, Nov 30, 2009 at 7:24 AM, Mauro Carvalho Chehab
> <mchehab@...hat.com> wrote:
> 
>> After the boot, a device can open the raw API, disabling any in-kernel
>> decoding/handling and handle IR directly. Alternatively, an udev rule
>> can load a different keymap based on some config written on a file.
> 
> This idea of the in-kernel decoding being disabled when the raw API is
> opened worries me.  What guarantees that the following scenario will
> not happen?
> 
> User uses apps which retrieve the decoded IR messages from the kernel.
> User installs an app which decodes messages via the raw API (not lirc).
> User's other applications no longer receive IR messages.
> 
> I know the assumption has been that "only lirc will use the raw API",
> but this seems like a poor assumption for an API design to me.

All those questions are theoretical, as we haven't a raw API code
already merged in kernel. So, this is just my understanding on how
this should work.

If the user wants to use the raw interface, it is because the in-kernel
decoding is not appropriate for his usage (at least while such application
is opened). So, not disabling the evdev output seems senseless.

Btw, this is the same behavior that happens when some application directly 
opens an evdev interface, instead of letting it to be redirected to stdin.

> A related question, what is an application developer who wishes to
> decode the raw IR signal (for whatever reason) to do?  Are they
> *required* to implement full decoding and feed all the messages back
> to the kernel so they don't break other applications?

If such application won't do it, the IR will stop working, while the
application is in use.

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/