From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Thu, 13 Apr 2006 11:10:53 +0000 Subject: Re: net interface renaming issue (+fix?) Message-Id: <20060413111053.GA26336@vrfy.org> List-Id: References: <20060409192140.73644723@eusebe> In-Reply-To: <20060409192140.73644723@eusebe> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org On Thu, Apr 13, 2006 at 12:36:27PM +0200, Marco d'Itri wrote: > On Apr 13, Kay Sievers wrote: >=20 > > But right, the longer term goal is that the notion of "physical devices" > > and "virtual devices" should not be exported that way by the kernel > > and therefore the use of these values, or the "device" link, or the > > symlinks, or a hardcoded sequence of sysfs pare= nt > > devices must be avoided for other things than temporary workarounds. >=20 > How should I rewrite this code then? >=20 > device_description() { > local bus=3D$(sysreadlink device/bus) > bus=3D${bus##*/} >=20 > if [ "$bus" =3D pci ]; then > local vendor_id=3D$(sysread device/vendor) > local device_id=3D$(sysread device/device) > echo -n "PCI device ${vendor_id#0x}:${device_id#0x}" > elif [ "$bus" =3D usb ]; then > local device=3D$(sysreadlink device) > if [ "$device" -a -e $device/../idVendor ]; then > local idVendor idProduct > read idVendor < $device/../idVendor || true > read idProduct < $device/../idProduct || true > printf 'USB device %x/%x' 0x$idVendor 0x$idProduct > else > echo -n "UNKNOWN USB device ($DEVPATH)" > fi > elif [ "$bus" ]; then > echo -n "UNKNOWN $bus device ($DEVPATH)" > else > echo -n "UNKNOWN device ($DEVPATH)" > fi >=20 > local driver=3D$(sysreadlink device/driver) > if [ "$driver" ]; then echo -n " (${driver##*/})"; fi > } In the end, we will have only one tree in sysfs and the devpath will contain the whole dependency of devices for every device. eth0 will have: /devices/pci0000:00/0000:00:1c.0/0000:02:00.0/eth0 as devpath instead of the current /class/net/eth0, which will only be a silent symlink to that location. When you get the event, you have to walk up the chain of parents in the devpath until you find the device you are looking for, you can't rely on a specific sequence, there may be a device inserted if the kernel device model needs that. That's why the "device" link does not make sense at that point. So you would walk up until you find a device of the subsystem you are looking for like "pci" or "usb" and then read these values. See the usb_id logic: http://www.kernel.org/git/?p=3Dlinux/hotplug/udev.git;a=3Dblob;h=85c6beda= 40e38d307d355aed4d8b789bb193cca4;hb=0C4a805bccbc52e48f972a87f83007fdb0ffe19= e;f=3Dextras/usb_id/usb_id.c#l250 It does not use any of these values and requests parent devices only by subsystem and can skip newly inserted parents in the devpath without breaka= ge. Udev already does all that today, so it may make sense to get udev to read these values and pass them to the script. Or we export them with rules to the environment (needs a change to udev to apply the format to the ENV key at that time). Or we provide some logic from udev_sysfs.c as a similar shell function to include by script users: http://www.kernel.org/git/?p=3Dlinux/hotplug/udev.git;a=3Dblob;h=DDc0b467= 90066e30bede2c9bb0026a271633795c;hb=0C4a805bccbc52e48f972a87f83007fdb0ffe19= e;f=3Dudev_sysfs.c#l196 Let me know if we should add something to udev itself to solve that. Thanks, Kay ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642 _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel