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]
Date:	Wed, 02 Jan 2008 19:59:15 +0000
From:	Paulo Marques <pmarques@...popie.com>
To:	Xiaofan Chen <xiaofanc@...il.com>
CC:	mgross <640e9920@...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)

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.

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ