Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 9 Nov 2008 17:39:06 +0100
From:      Rink Springer <rink@FreeBSD.org>
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:  <20081109163906.GF78524@rink.nu>
In-Reply-To: <20081109162835.GE78524@rink.nu>
References:  <20081109120257.GA78524@rink.nu> <200811091515.26123.hselasky@c2i.net> <20081109154722.GC78524@rink.nu> <200811091700.06932.hselasky@c2i.net> <20081109162835.GE78524@rink.nu>

next in thread | previous in thread | raw e-mail | index | archive | help
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? What if one of them
dies, etc... I'd like to avoid the whole 'the same process can...'
alltogether for this purpose.

(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? :-)

-- 
Rink P.W. Springer                                - http://rink.nu
"Anyway boys, this is America. Just because you get more votes doesn't
 mean you win." - Fox Mulder



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