lkml.org 
[lkml]   [2008]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] libusb / in-kernel usb driver criteria (was: USB driver for talking to the Microchip PIC18 boot loader)
Xiaofan Chen wrote:
> On Dec 30, 2007 11:53 AM, mgross <640e9920@gmail.com> wrote:
>> [...]
>> What is the linux-usb policies on new drivers that could be
>> implemented in user space? When does a kernel driver make sense over
>> a libusb one?
>
> That would be interesting to know.

I myself have been faced with this question before, and I think we
should try to clarify this by adding a document with some guidelines to
Documentation/usb.

So, to get the ball rolling, here are some factors that IMHO help decide
in which side to implement a driver:

- if the driver ties a hardware device to an existing in-kernel
interface (network, block, serial, bluetooth, video4linux, etc.), it
should probably be implemented in-kernel.

- on the other hand, if the driver doesn't use an existing kernel
interface and creates a new user-visible interface that is going to be
used by a single userspace application, it should probably be done in
userspace.

- if it is going to be used by several applications it could still be
implemented as a library, but it starts moving into the gray area.

- performance might be a reason to move to kernel space, but I don't
think it matters for transfer rates below 10Mbytes/sec or so.

Anyway, this is just MHO, so feel free to discuss this further. I'm
simply volunteering to sum up this thread into a patch to add a
Documentation/usb/userspace_drivers.txt (or something like that), so
that we can help future developers decide where to write their drivers.

--
Paulo Marques - www.grupopie.com

"Very funny Scotty. Now beam up my clothes."


\
 
 \ /
  Last update: 2008-01-02 21:01    [W:0.088 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site