Patch to convert usb2 to use cdev

Hans Petter Selasky hselasky at
Sun Nov 9 08:53:24 PST 2008

Hi Rick,

On Sunday 09 November 2008, Rink Springer wrote:
> On Sun, Nov 09, 2008 at 05:28:35PM +0100, Rink Springer wrote:
> > I think it makes sense to say that if /dev/ugenX.Y is opened, you
> > shouldn't be able to open /dev/ugenX.Y.Z, right? However, what happends
> > if /dev/ugenX.Y.Z is opened? I'd think that opening /dev/ugenX.Y would
> > be fine, but any ioctl() dealing with the corresponding endpoint Z
> > should be denied.
> Come to think of it, I'd expect that an application would either:
> 1) Open /dev/ugenX.Y and chat with whatever endpoints it needs
> 2) Open /dev/ugenX.Y.{Z1,Z2} and chat with them


> But not mix these - thus, if a device opens /dev/ugenX.Y, I'd say it
> should have complete control since it asked for this; if it opens
> /dev/ugenX.Y.Z, anyone else can open /dev/ugenX.Y.Z' if Z' != Z.
> You see, I'd prefer to keep the implementation reasonably easy - for
> example, what happends if a process forks off extra threads which each
> open a /dev/usbX.Y.Z device? Should they be allowed? 

I would say yes. For debugging purpose only. Sometimes you need to do things 
out of the ordinary, and then this is a very easy way to do it.

> What if one of them  
> dies, etc... I'd like to avoid the whole 'the same process can...' 
> alltogether for this purpose.

LibUSB20 currently uses the /dev/ugenX.Y for all device access. /dev/ugenX.Y.Z 
is mostly there for backwards compatibility and debugging.

With some minor tweaks to devfs the "magic" I'm already doing, would become 
much simpler.

> (Of course, the zero endpoint should be magic, since you need it to
> suspend/resume a device etc.)
> Does this make sense to you (or anyone else for what matter? :-)

Yes, I think you are getting it now :-)


More information about the freebsd-usb mailing list