Re: HEADSUP usb2 (usb4bsd) to become default in 2 weeks.

From: Thierry Herbelot <thierry.herbelot_at_free.fr>
Date: Tue, 23 Dec 2008 20:48:06 +0100
Le Tuesday 23 December 2008, Rink Springer a écrit :
> On Tue, Dec 23, 2008 at 08:08:08PM +0100, Ed Schouten wrote:
> > * Hans Petter Selasky <hselasky_at_c2i.net> wrote:
> > > On Tuesday 23 December 2008, Dag-Erling Sm?rgrav wrote:
> > > > There are serious issues with the permissions model, which were
> > > > raised in Strasbourg and AFAIK never addressed.
> > >
> > > This is more complicated than you think. If you require a change in
> > > this area than please point me to an existing example implementing
> > > something similar. I know about the "kern_priv()" function, but there
> > > are no specific groups for USB, which needs to be discussed. The
> > > current implementation is good enough for most use cases in my opinion.
> >
> > Just create device nodes in devfs. Let devfs handle the permissions. If
> > they are insufficient, then we should add ACL support to devfs.
>
> Due to the design of USB2, this isn't quite as obvious as it may seem;
> for example, an USB device has multiple endpoints, and if some process
> opens endpoint 1 and 3, you don't want to block another process from
> opening endpoint 2, for example. There are a lot of interesting
> combinations possible, and this is only the tip of the iceberg :-)

Hello,

Speaking of permissions, please do not forget that endpoint 0 may be 
simultaneously used by multiple processes (for multiple interleaved USB 
requests).

As a Me-Too : one current difficulty with usb2 is the loss of device nodes for 
addressing individual endpoints.

One the other hand, the performance is so much better .... impressive even 
from userland, when using libusb20.

I just have found what may be an issue, which is : reading from bulk 
endpoints, I can get data if the reads are in two separate processes, but not 
from two threads in the same process.

	Thanks for the good work

	TfH
>
> Regards,
Received on Tue Dec 23 2008 - 19:21:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:39 UTC