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: <m37hsxtrnr.fsf@intrepid.localdomain>
Date:	Tue, 08 Dec 2009 16:24:40 +0100
From:	Krzysztof Halasa <khc@...waw.pl>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Jon Smirl <jonsmirl@...il.com>,
	Mauro Carvalho Chehab <mchehab@...hat.com>,
	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 <dmitry.torokhov@...il.com> writes:

> No, the IR core responsible for registering receivers and decoders.

Well. This makes me think now that LIRC can be just "another decoder".

>> Those are simple things. The only part which needs to be stable is the
>> (in this case LIRC) kernel-user interface.
>
> For which some questions are still open. I believe Jon just oulined some
> of them.

Those are rather "how does it work", not "let's change something because
it's not optimal".

> No we do not. We do not merge something that we expect to rework almost
> completely (no, not the lirc-style device userspace inetrface, although
> even it is not completely finalized I believe, but the rest of the
> subsystem).

I don't think we need to rework it almost completely. Perhaps we need to
change a hook here or there.

> No, not at all. You merge core subsystem code, then start addig
> decoders...

You must have at least one common decoder merged with the core code,
otherwise you don't know if the core is adequate. And you have to have
at least one common input device.

But perhaps it is a workable idea after all, given the "another
decoder".
-- 
Krzysztof Halasa
--
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/