Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 9 Nov 2008 17:55:23 +0100
From:      Hans Petter Selasky <hselasky@c2i.net>
To:        Rink Springer <rink@freebsd.org>
Cc:        usb@freebsd.org, freebsd-usb@freebsd.org
Subject:   Re: Patch to convert usb2 to use cdev
Message-ID:  <200811091755.23962.hselasky@c2i.net>
In-Reply-To: <20081109163906.GF78524@rink.nu>
References:  <20081109120257.GA78524@rink.nu> <20081109162835.GE78524@rink.nu> <20081109163906.GF78524@rink.nu>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200811091755.23962.hselasky>