Patch to convert usb2 to use cdev
Hans Petter Selasky
hselasky at c2i.net
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
Right.
>
> 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 :-)
--HPS
More information about the freebsd-usb
mailing list