Date:	Thu, 3 Jan 2008 15:08:55 -0800
From:	mgross <640e9920@...il.com>
To:	Paulo Marques <pmarques@...popie.com>
Cc:	Xiaofan Chen <xiaofanc@...il.com>,
	Alan Stern <stern@...land.harvard.edu>,
	linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org
Subject: Re: [RFC] libusb / in-kernel usb driver criteria (was: USB driver
	for talking to the Microchip PIC18 boot loader)

On Wed, Jan 02, 2008 at 07:59:15PM +0000, Paulo Marques wrote:
> Xiaofan Chen wrote:
>> On Dec 30, 2007 11:53 AM, mgross <640e9920@...il.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.

Agreed, I think this is clear.

>
>  - 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.
>

To me this is still grey, and comes down to opinions of style.  I
happen to like the way code looks when things are split up into
drivers (that know a lot about the hardware and protects it from data
that will turn it into a brick) and application code that talks to the
interface defined by the driver.

The libusb based applications I've seen tend to be quite convoluted
and do a poor job of separating the USB protocol from the application
protocol for talking to the device.

I don't think there is a clear way to define when to do a kernel
driver vrs just use a libusb thing, other than if no one does a kernel
driver for a device then users are stuck with the libusb applications.

If someone steps up and does one and is willing to support it, then to
me its like, "whatever" add the driver. 

BTW I don't know if its worth to code bloat for my driver as I ponder
this issue now.  I like the way non-libusb applications look more but
I guess I could create a lib of api-wrappers to the libusb interface
and use that, but I really think its less code to create a simple
kernel driver.  

If it where up to me, I would say if the LOC is smaller to have a
kernel driver and application then a kernel driver is justified
otherwise its not.

--mgross



>  - 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."
--
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