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: <4B117E76.4000109@s5r6.in-berlin.de>
Date:	Sat, 28 Nov 2009 20:48:06 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Jon Smirl <jonsmirl@...il.com>
CC:	Maxim Levitsky <maximlevitsky@...il.com>,
	Krzysztof Halasa <khc@...waw.pl>,
	Christoph Bartelmus <christoph@...telmus.de>,
	jarod@...sonet.com, awalls@...ix.net, dmitry.torokhov@...il.com,
	j@...nau.net, jarod@...hat.com, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
	mchehab@...hat.com, superm1@...ntu.com
Subject: Re: [RFC] What are the goals for the architecture of an in-kernel
 IR 	system?

Jon Smirl wrote:
> On Sat, Nov 28, 2009 at 2:30 PM, Stefan Richter
> <stefanr@...6.in-berlin.de> wrote:
>> Jon Smirl wrote:
>>> If these drivers are for specific USB devices it is straight forward
>>> to turn them into kernel based drivers. If we are going for plug and
>>> play this needs to happen. All USB device drivers can be implemented
>>> in user space, but that doesn't mean you want to do that. Putting
>>> device drivers in the kernel subjects them to code inspection, they
>>> get shipped everywhere, they autoload when the device is inserted,
>>> they participate in suspend/resume, etc.
>> Huh?  Userspace implementations /can/ be code-reviewed (but they can't
>> crash your machine), they /can/ be and are shipped everywhere, they /do/
>> auto-load when the device is inserted.  And if there should be an issue
>> with power management (is there any?), then improve the ABI and libusb
>> can surely be improved.  I don't see why a device with a userspace
>> driver cannot be included in power management.
> 
> If you want a micro-kernel there are plenty to pick from. Linux has
> chosen not to be a micro-kernel. The Linux model is device drivers in
> the kernel.

Total nonsense.  Neither am I arguing for a micro-kernel, nor are
userspace drivers alien to Linux.  Not at all.
-- 
Stefan Richter
-=====-==--= =-== ===--
http://arcgraph.de/sr/
--
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/