Date: Tue, 7 Sep 2010 21:13:25 +0200 From: Nick Hibma <nick@van-laarhoven.org> To: Alexandr Rybalko <ray@dlink.ua> Cc: freebsd-usb@freebsd.org Subject: Re: USB serial device naming Message-ID: <03EA4629-81F5-442C-9064-95E1A265D8AD@van-laarhoven.org> In-Reply-To: <20100505121841.ce3cf358.ray@dlink.ua> References: <43EC7D78-31E5-4B86-9316-002AE650727A@tlb.org> <201005042027.o44KRete011712@lava.sentex.ca> <201005050952.15632.hselasky@c2i.net> <201005051046.31093.freebsd-usb@dino.sk> <20100505121841.ce3cf358.ray@dlink.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>> 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: >>>>=20 >>>> /dev/cuaU1.1.<iface_number>.<optional_sub_modem_unit> >>>>=20 >>>> The only problem is: Will we break any existing applications? >>>>=20 >>>=20 >>> Well, yes, to some extent :) Problem with this naming convention is = name=20 >>> changes with every port change - that is, if you pull USB cable out = and plug=20 >>> it in another port. There was already some older thread about naming = on=20 >>> freebsd-usb list (end of April 2009). But if devd receives all = necessary=20 >>> informations in attach event, then it is possible to rewrite config = files or=20 >>> create symlink in /dev directory or something like this to handle = this=20 >>> situation. >=20 > 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=3D0x0af0 product=3D0x7601 devclass=3D0xff = devsubclass=3D0xff sernum=3D"" release=3D0x0000 intclass=3D0xff = intsubclass=3D0xff at port=3D2 interface=3D0 vendor=3D0x0af0 = product=3D0x7601 devclass=3D0xff devsubclass=3D0xff sernum=3D"" = release=3D0x0000 intclass=3D0xff intsubclass=3D0xff on uhub1' Pushing table setting device-name=3Du3g0 setting vendor=3D0x0af0 setting product=3D0x7601 setting devclass=3D0xff setting devsubclass=3D0xff setting sernum=3D setting release=3D0x0000 setting intclass=3D0xff setting intsubclass=3D0xff Processing attach event How do I get to the cuaU10.0 device here? As far as I can see there is = no way to do this.=20 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. If no one objects I will submit a patch to resolve problem 2). Nick=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?03EA4629-81F5-442C-9064-95E1A265D8AD>