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 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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ