linux-kernel - Re: [RFC] libusb / in-kernel usb driver criteria

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]

Message-ID: <20080111171006.GA6718@kroah.com>
Date:	Fri, 11 Jan 2008 09:10:06 -0800
From:	Greg KH <greg@...ah.com>
To:	mgross <640e9920@...il.com>
Cc:	Paulo Marques <pmarques@...popie.com>,
	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

On Thu, Jan 03, 2008 at 03:08:55PM -0800, mgross wrote:
> 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?

Good question.

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

Yes, this the primary decision point, everything after this depends on
lots of variables :)

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

Agreed.  It all depends on the situation, we have kernel drivers for
devices that can be done in userspace, but not as cleanly or nicely, and
so, they stay as kernel drivers.

In the end, it comes down to individual cases, so let's handle them at
that level, it's easier that way.

thanks,

greg k-h
--
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/