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:	Tue, 08 Dec 2009 09:58:53 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
CC:	Jon Smirl <jonsmirl@...il.com>, Krzysztof Halasa <khc@...waw.pl>,
	hermann pitton <hermann-pitton@...or.de>,
	Christoph Bartelmus <lirc@...telmus.de>, awalls@...ix.net,
	j@...nau.net, jarod@...hat.com, jarod@...sonet.com,
	kraxel@...hat.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR  system?

Dmitry Torokhov wrote:
> On Mon, Dec 07, 2009 at 09:44:14PM -0200, Mauro Carvalho Chehab wrote:

>>> What about capabilities of the receiver, what frequencies?
>>> If a receiver has multiple frequencies, how do you report what
>>> frequency the data came in on?
>> IMO, via sysfs.
> 
> We probably need to think what exactly we report through sysfs siunce it
> is ABI of sorts.

Yes, sure.

Probably, the exact needs will popup only when we start to actually writing that
part of the core.

My intention for now is to just create a /sys/class/irrcv, with one node
per each IR receiver and adding a protocol enumeration/selection node
there, and add some capabilities for the in-kernel decoders and lirc_dev
to create new nodes under that class.

When the decoders/lirc_dev patches popup, we'll need to review those sysfs
API's.
 
>>> What about multiple apps simultaneously using the pulse data?
>> IMO, the better is to limit the raw interface to just one open.
>>
> 
> Why woudl we want to do this? Quite often there is a need for "observer"
> that maybe does not act on data but allows capturing it. Single-user
> inetrfaces are PITA. 

That should work fine as well, but I'm not sure how we'll detect overrun with
several kfifo readers.

>>> How big is the receive queue?
>> It should be big enough to receive at least one keycode event. Considering that
>> the driver will use kfifo (IMO, it is a good strategy, especially since you
>> won't need any lock if just one open is allowed), it will require a power of two size.
>>
> 
> Would not it be wither driver- or protocol-specific?

Probably.

> 
>>> How does access work, root only or any user?
>> IMO, it should be the same requirement as used by an input interface.
>>
>>> How are capabilities exposed, sysfs, etc?
>> IMO, sysfs.
>>
>>> What is the interface for attaching an in-kernel decoder?
>> IMO, it should use the kfifo for it. However, if we allow both raw data and
>> in-kernel decoders to read data there, we'll need a spinlock to protect the
>> kfifo.
>>
> 
> I think Jon meant userspace interface for attaching particular decoder.

I don't think we need an userspace interface for the in-kernel decoders. All
it needs is to enable/disable the protocol decoders, imo via sysfs interface.

>>> If there is an in-kernel decoder should the pulse data stop being
>>> reported, partially stopped, something else?
>> I don't have a strong opinion here, but, from the previous discussions, it
>> seems that people want it to be double-reported by default. If so, I think
>> we need to implement a command at the raw interface to allow disabling the
>> in-kernel decoder, while the raw interface is kept open.
> 
> Why don't you simply let consumers decide where they will get their data?

How?

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/