Re: A few questions/observations and a contribution for udev and network devices

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

On Tue, Mar 28, 2006 at 01:57:23PM +0100, David Goodenough wrote:
> I recently installed Linux (2.6.16) on a MiniITX box onto which I had added
> a four port ethernet card.  This box is operating as a router and tunnel
> destination in a curious network, and it needs to operate 24/7 unattended.
> 
> The on-board ethernet port uses the via-rhine driver and the four port card
> the natsemi driver.
> 
> I needed to make sure that whatever happened during boot the ports
> were always correctly assigned to the right eth? devices, but sometimes
> the via-rhine got there first as eth0, sometimes the natsemi got there
> first and the via-rhine became eth4.

You can manually load the modules from init, then the order will probably not
change.

> So I looked to udev to give me persistant naming, and I fixed on using
> ethn? for the natsemis and ethv0 for the via-rhine.  I did not want to 
> use the MAC addresses as I have a cold backup to which I copy the 
> disk image (its a solid state flash MIDE drive).
> 
> But as far as I could tell the only way to generate the numbers was to
> use %n, and that is related to the original kernel allocated eth? number.
> That of course still changes.  So I wrote a little script
> (/usr/local/bin/nextdev):-
> 
> #!/bin/bash
> #set -x
> 
> K=0
> while ip addr show dev $1$K >/dev/null 2>&1; do
> 	let K=$K+1
> 	done
> echo $1$K
> 
> which found me the first unused number for this sequence.  Then
> I used that in the udev rules:-
> 
> DRIVER="natsemi", PROGRAM="/usr/local/bin/nextdev ethn", NAME="%c"
> DRIVER="via-rhine", PROGRAM="/usr/local/bin/nextdev ethv", NAME="%c"
> 
> and I have achieved my result.  
> 
> Maybe what I am trying to do is odd, but I was a little surprised to find that
> this script (or something like it) did not already exist somewhere on the net,
> but Google failed to find anything that looked useful.  

The problem with every simple enumeration like this is that if you
would add another device that matches your rule, all the interfaces
will be mixed up again.
I don't see any sane option besides creating custom rules and using
the bus id of the pci device to identify the device persistently with
a name that is not computed by simply appending a number to the device
at every reboot.

Unlike the mac addresses that are different from box to box, the bus
id's should be identical on the same mainboards.

You may try:
  udevinfo -a -p /sys/class/net/eth0
and see if you can use the pci bus id's.

> That set me thinking about network devices and udev.  I came across a 
> project on SourceForge to put all net devices into /dev (like the current 
> /dev/net/tun? entries) and I thought that looked like a good idea.  It has
> always struck me as odd that network devices are the only ones which
> do not appear in /dev, but I appreciate that there is a lot of history there.

Yeah, network devices don't really match file operations. But yeah, it's
a bit sad that we don't have something like "alias names" for netifs like we
can have symlinks to device names.

> It also ocurred to me that actually udev could go one further and take
> over what is currently done by the likes of ifplugd (and its wireless
> equivalents like wpa-supplicant).  Well not take over the function, but
> integrate the function into the udev framework.  You already have
> hotplug devices like disks, memory and processors, why not network
> devices.  You do of course have support for loading the drivers when
> the device becomes present, but the events surrounding the link going
> up and down (or wireless base stations coming into view) are semantically
> much the same.

No, that's a whole different story. Udev does not "monitor" any device,
it just acts when devices come and go from the kernel and it plugs
userspace into that process.

Network devices in a desktop environment are handled by NetworkManager
which knows about the link state and all the crazy configurations for
network devices. While a simple link state may change may be possible to
integrate here for some drivers that don't need workarounds, it's absolutely
impossible to do sane wireless network handling at the level udev works.

> With recent versions of KDE you even get an automounter
> when you put in a CD or floppy into the drive, which is surely very like
> a network link coming ready.  Or is that hald, I get confused sometimes.

Higher level storage handling is all done by HAL, especially polling
removable media devices where the kernel does not detect changes on its
own.

> Sorry if all this has already been discussed, but I could not find how to
> subscribe to this list or where the archives are (the readme only gives this
> email address, not instructions on where to subscribe).  

  https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel


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