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: <20091129190435.6500ac84@lxorguk.ukuu.org.uk>
Date:	Sun, 29 Nov 2009 19:04:35 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Ray Lee <ray-lk@...rabbit.org>
Cc:	Maxim Levitsky <maximlevitsky@...il.com>,
	Andy Walls <awalls@...ix.net>, 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,
	mchehab@...hat.com, stefanr@...6.in-berlin.de, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR  system?

> Jon is asking for an architecture discussion, y'know, with use cases.
> Maxim seems to be saying it's obvious that what we have today works
> fine. Except it doesn't appear that we have a consensus that
> everything is fine, nor an obvious winner for how to reduce the
> complexity here and keep the kernel in a happy, maintainable state for
> the long haul.

The important point is that this is not an A or B discussion. There are
lots of ways to tackle it that are neither. If you look at things like
complex video format handling it is done in user space but with an
infrastructure to handle it.

I don't believe putting it in the kernel is the alternative to the
current setup. Cleaning up the way what we have today is presented to
applications is perfectly possible without a whole new pile of kernel
crap, because evdev was designed sensibly in the first place to allow
userspace added events.

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