Messages in this thread | | | Date | Wed, 02 Jan 2008 19:59:15 +0000 | From | Paulo Marques <> | Subject | Re: [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."
| |