[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B117A4C.1070304@s5r6.in-berlin.de>
Date: Sat, 28 Nov 2009 20:30:20 +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:
> 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.
--
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