Re: net interface renaming issue (+fix?)

[Kay Sievers <kay.sievers@vrfy.org>]

On Thu, Apr 13, 2006 at 12:36:27PM +0200, Marco d'Itri wrote:
> On Apr 13, Kay Sievers <kay.sievers@vrfy.org> wrote:
> 
> > 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
> > <subsystem:kernel_name> symlinks, or a hardcoded sequence of sysfs parent
> > devices must be avoided for other things than temporary workarounds.
> 
> How should I rewrite this code then?
> 
> device_description() {
>   local bus=$(sysreadlink device/bus)
>   bus=${bus##*/}
> 
>   if   [ "$bus" = pci ]; then
>     local vendor_id=$(sysread device/vendor)
>     local device_id=$(sysread device/device)
>     echo -n "PCI device ${vendor_id#0x}:${device_id#0x}"
>   elif [ "$bus" = usb ]; then
>     local device=$(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
> 
>   local driver=$(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=linux/hotplug/udev.git;a=blob;h…c6beda40e38d307d355aed4d8b789bb193cca4;hb\f4a805bccbc52e48f972a87f83007fdb0ffe19e;f=extras/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 breakage.

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=linux/hotplug/udev.git;a=blob;hÝc0b46790066e30bede2c9bb0026a271633795c;hb\f4a805bccbc52e48f972a87f83007fdb0ffe19e;f=udev_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=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
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