Date: Wed, 8 Sep 2010 10:08:52 +0200 From: Bernd Walter <ticso@cicely7.cicely.de> To: Hans Petter Selasky <hselasky@c2i.net> Cc: freebsd-usb@freebsd.org Subject: Re: USB serial device naming Message-ID: <20100908080852.GB72692@cicely7.cicely.de> In-Reply-To: <201009080900.46802.hselasky@c2i.net> References: <43EC7D78-31E5-4B86-9316-002AE650727A@tlb.org> <20100505121841.ce3cf358.ray@dlink.ua> <03EA4629-81F5-442C-9064-95E1A265D8AD@van-laarhoven.org> <201009080900.46802.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 08, 2010 at 09:00:46AM +0200, Hans Petter Selasky wrote: > 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.<iface_number>.<optional_sub_modem_unit> > > >>>> > > >>>> 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<bus>.<addr>.<iface>[.<sub_unit>] I come back later to your suggestion. > 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 . What I missed most with the USB serial concept is that there is not easy way to get from the driver instance to the ucom instance. For other devices it is easy to have devd setup softlinks depending on e.g. serial numbers. devd gets bus addresses, so it is possible to easily setup softlinks for your suggested device naming without knowin the ucom instance. But it breaks another feature. We ship /etc/remote prefilled with ucom[012] entries. umass devices have a similar problem - you don't know the da* nodes you'll get. In many cases like harddisks, picturecards, ... you can get away with labels, but if you regularily need to partion brand new flash cards you need to be very carefull about devicenames to not overwrite the wrong media. > > 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. There is no single set per device. ucom already has /dev/ttyU* and /dev/cuaU* in different variants with and without .init and .lock extensions. > You mean in the device name, not in the inode? You better know the ucom instance number via devinfo - then devd can setup all required softlinks because with the instance number you also know all nodenames. The path - as suggested in the original post - is also interesting. Knowing the nodes allows you to setup softlinks, but you need to know the device as well and not everyone has a serial number, but usually is conneted using the same hub/port chain. The bus address is useless here, because it is dynamic. devinfo already contains informations about the uplink port, but requires to travel the chain yourself and in single-user-mode (when devd gets the bootmessages) you don't have many tools for scripting available. -- B.Walter <bernd@bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100908080852.GB72692>