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

[David Goodenough <david.goodenough@linkchoose.co.uk>]

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.

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.  

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.

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.  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.

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).  

Obviously I am not subscribed, but would happily subscribe if I knew how.

Regards

David


-------------------------------------------------------
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