From owner-freebsd-usb@FreeBSD.ORG Tue Sep 7 19:25:35 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 9AE6610656BA; Tue, 7 Sep 2010 19:25:35 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from cpsmtpb-ews10.kpnxchange.com (cpsmtpb-ews10.kpnxchange.com [213.75.39.15]) by mx1.freebsd.org (Postfix) with ESMTP id 0B53B8FC16; Tue, 7 Sep 2010 19:25:34 +0000 (UTC) Received: from cpbrm-ews20.kpnxchange.com ([10.94.84.151]) by cpsmtpb-ews10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Sep 2010 21:13:30 +0200 Received: from CPSMTPM-EML106.kpnxchange.com ([195.121.3.10]) by cpbrm-ews20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Sep 2010 21:13:30 +0200 Received: from uitsmijter.van-laarhoven.org ([81.207.207.222]) by CPSMTPM-EML106.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18222); Tue, 7 Sep 2010 21:13:28 +0200 Received: from hillary.van-laarhoven.org (Hillary.van-laarhoven.org [10.66.0.144]) (authenticated bits=0) by uitsmijter.van-laarhoven.org (8.14.4/8.14.4) with ESMTP id o87JDQaL044802; Tue, 7 Sep 2010 21:13:27 +0200 (CEST) (envelope-from nick@van-laarhoven.org) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nick Hibma In-Reply-To: <20100505121841.ce3cf358.ray@dlink.ua> Date: Tue, 7 Sep 2010 21:13:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <03EA4629-81F5-442C-9064-95E1A265D8AD@van-laarhoven.org> 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> To: Alexandr Rybalko X-Mailer: Apple Mail (2.1081) X-Spam-Status: No, score=-15.9 required=5.0 tests=ALL_TRUSTED, J_CHICKENPOX_12, MR_DIFF_MID, SMILEY, T_RP_MATCHES_RCVD, USER_IN_WHITELIST, USER_IN_WHITELIST_TO autolearn=no version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on uitsmijter.van-laarhoven.org X-OriginalArrivalTime: 07 Sep 2010 19:13:28.0771 (UTC) FILETIME=[C0EE2130:01CB4EC0] X-RcptDomain: freebsd.org Cc: freebsd-usb@freebsd.org 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: Tue, 07 Sep 2010 19:25:35 -0000 >>>> 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.. >>>>=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=