From owner-freebsd-arch@FreeBSD.ORG Sat Mar 20 23:15:00 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF79316A4CE for ; Sat, 20 Mar 2004 23:15:00 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDDE643D2F for ; Sat, 20 Mar 2004 23:14:59 -0800 (PST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i2L7CHUS094930 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 21 Mar 2004 08:12:19 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i2L7B3hn032151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Mar 2004 08:11:04 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id i2L7B3Ok063365; Sun, 21 Mar 2004 08:11:03 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id i2L7B19s063364; Sun, 21 Mar 2004 08:11:01 +0100 (CET) (envelope-from ticso) Date: Sun, 21 Mar 2004 08:11:01 +0100 From: Bernd Walter To: "M. Warner Losh" Message-ID: <20040321071100.GH33602@cicely12.cicely.de> References: <20040320052007.GC33602@cicely12.cicely.de> <20040320.184336.88475380.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040320.184336.88475380.imp@bsdimp.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.61 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on cicely5.cicely.de cc: ticso@cicely12.cicely.de cc: arch@freebsd.org cc: ticso@cicely.de Subject: Re: Opinions about using USB serial numbers X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Mar 2004 07:15:01 -0000 On Sat, Mar 20, 2004 at 06:43:36PM -0700, M. Warner Losh wrote: > In message: <20040320052007.GC33602@cicely12.cicely.de> > Bernd Walter writes: > : I have a lot to do with systems using many USB devices of the same > : kind. > : Currently device are named acording to their probing order. > : That result in the problematic that device names can change after > : reboot or replugging in different order. > : > : I would like to add functionality for creating alias devnodes > : including the serial numbers (if the device has one setup). > : E.g. for a ucom(4) device you will get /dev/ucom0 and ucom.serialnumber. > : If the device has no serial numer there will be just /dev/ucom0 > : as befor. > : > : Another solution could be to create the nodes in a tree form: > : /dev/usbchannel0/hubport1/pubport2/ucom > : That would work for devices without serial numbers too, but I > : personally dislike this way. > > I'd rather that we have a generic binding of a device instance number > to a pnp location. Currently we have non really working - even cam binding is evil because it's a boot time only. > However, having said that, you can use devd to extract the information > from the node and then create a symbolic link... OK - lets try it with devd. Usefull devd support is required anyway. That's what I get on plugging in a device: Processing event '? at on uhub2' Pushing table Processing nomatch event Popping table Processing event '+ubser0 at on uhub2' Pushing table device-name=ubser0 Processing attach event I think the '?' one is because no driver attaches at device level. ubser is an interface level driver as most USB ones. What I need is the following for devices: vendor-id, device-id, device-class, device-protocoll, vendor-string, device-string, serial-id. At interface level additionally: interface-class, interface-subclass, interface-protocoll, interface-string. I've seen some places where bus_child_pnpinfo_str() and bus_child_location_str() was used for extended informations. Is this all I have to implement? Can I put the above data in it or are there any restrictions? It seems that dv_pnpinfo[128] could be to small for all of them. We can discuss if strings are required, but also USB serial number is a (unicode)string and strings can be 254 bytes long. What about whitespace in strings? Does usbd still serve any usefull purpose after having the above data via devctl? -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de