From owner-freebsd-usb@FreeBSD.ORG Wed Sep 8 07:04:51 2010 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 7842D10656AA for ; Wed, 8 Sep 2010 07:04:51 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id D4E998FC14 for ; Wed, 8 Sep 2010 07:04:50 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=U2hIrLQqCdA2RCeqEnOseJoiiWVOUJG87SgQLk1lgUQ= c=1 sm=1 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=wldHJnkDx54rNUzNyRIA:9 a=BnDVymmpiK5x9PZ2JDoA:7 a=8_abSCYEPygjjg5TOSwI8_rOYwAA:4 a=wPNLvfGTeEIA:10 a=M_cd827UyEatLweu:21 a=gFmQH5WNfDgVm8h9:21 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 17746778; Wed, 08 Sep 2010 09:04:44 +0200 From: Hans Petter Selasky To: freebsd-usb@freebsd.org Date: Wed, 8 Sep 2010 09:00:46 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <43EC7D78-31E5-4B86-9316-002AE650727A@tlb.org> <20100505121841.ce3cf358.ray@dlink.ua> <03EA4629-81F5-442C-9064-95E1A265D8AD@van-laarhoven.org> In-Reply-To: <03EA4629-81F5-442C-9064-95E1A265D8AD@van-laarhoven.org> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009080900.46802.hselasky@c2i.net> Cc: Subject: Re: USB serial device naming 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: Wed, 08 Sep 2010 07:04:51 -0000 On Tuesday 07 September 2010 21:13:25 Nick Hibma wrote: > >>>> Maybe you can make PR on the issue and assign it to USB. Currently > >>>> there is no way of knowing which /dev/cuaUXXX belongs to which USB > >>>> device. Probably we can add the USB bus and address number as a part > >>>> of the device coordinates. So that /dev/ugen1.1 only creates > >>>> /dev/cuaU1.1.xxx entries. And then we can also remove the current > >>>> unit number allocation structure I guess, if we use: > >>>> > >>>> /dev/cuaU1.1.. > >>>> > >>>> The only problem is: Will we break any existing applications? > >>> > >>> Well, yes, to some extent :) Problem with this naming convention is > >>> name changes with every port change - that is, if you pull USB cable > >>> out and plug it in another port. There was already some older thread > >>> about naming on freebsd-usb list (end of April 2009). But if devd > >>> receives all necessary informations in attach event, then it is > >>> possible to rewrite config files or create symlink in /dev directory > >>> or something like this to handle this situation. > > > > I think better way is use device connection path in name. > > User know to which port of hub they attach device, so name like > > /dev/cuaU.h0p1.h2p3 (root hub 0, port 1, hub 2, port 3 ) have all > > information user need and this name not changing between reboot`s. May > > by we have way make naming more simple, but we really need path > > somewhere in device name. > > Two things are needed: > > 1) path to the device so you can distinguish two identical devices. > > 2) map u3gN to cuaUX.Y > > My problem is the latter: > > Processing event '+u3g0 vendor=0x0af0 product=0x7601 devclass=0xff > devsubclass=0xff sernum="" release=0x0000 intclass=0xff intsubclass=0xff > at port=2 interface=0 vendor=0x0af0 product=0x7601 devclass=0xff > devsubclass=0xff sernum="" release=0x0000 intclass=0xff intsubclass=0xff > on uhub1' Pushing table > setting device-name=u3g0 > setting vendor=0x0af0 > setting product=0x7601 > setting devclass=0xff > setting devsubclass=0xff > setting sernum= > setting release=0x0000 > setting intclass=0xff > setting intsubclass=0xff > Processing attach event > Hi, > How do I get to the cuaU10.0 device here? As far as I can see there is no > way to do this. I think we should use the following format: cuaU..[.] Then you can match by ugenX.Y unit. Possibly we could add this information to the processing event. I would like to avoid having too much information in the device name, which is not really needed. Then we can also remove the unit allocator in usb/serial/usb_serial.c . > > The main problem is the strange way the minor number is assigned to the > cuaU device. But having the major and minor numbers for the cuaU device > per u3g instance would be sufficient. Through a sysctl for example, or as > extra information in the attach. You mean in the device name, not in the inode? > > If no one objects I will submit a patch to resolve problem 2). Please send a patch for review. --HPS