From owner-freebsd-usb@FreeBSD.ORG Sun Nov 9 16:53:24 2008 Return-Path: Delivered-To: freebsd-usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96D9C106564A; Sun, 9 Nov 2008 16:53:24 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.swipnet.se [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id CDDC38FC0A; Sun, 9 Nov 2008 16:53:23 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MdMrz2CnUUkA:10 a=d6BVkb5LuPPVEe4iNQMLyA==:17 a=q3P2X_nk9Hctx0a1uNUA:9 a=j2kp9weOVhrKCxJNGggXKwxtH58A:4 a=50e4U0PicR4A:10 Received: from [62.113.135.6] (account mc467741@c2i.net [62.113.135.6] verified) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 756777338; Sun, 09 Nov 2008 17:53:22 +0100 From: Hans Petter Selasky To: Rink Springer Date: Sun, 9 Nov 2008 17:55:23 +0100 User-Agent: KMail/1.9.7 References: <20081109120257.GA78524@rink.nu> <20081109162835.GE78524@rink.nu> <20081109163906.GF78524@rink.nu> In-Reply-To: <20081109163906.GF78524@rink.nu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811091755.23962.hselasky@c2i.net> Cc: usb@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Patch to convert usb2 to use cdev X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2008 16:53:24 -0000 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