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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ