This is from an old discussion several months ago: http://lkml.org/lkml/2009/3/24/357 http://lkml.org/lkml/2009/3/24/380 Basically the issue is that between a race in udev and PCI scan order the ethX IDs may not be consistent between reboots. The idea is to use a mechanism similar to how disks now can be accessed by their LABEL/PATH/UUID instead of raw /dev/sdX ids. example udev config: SUBSYSTEM=="net", SYMLINK+="net/by-mac/$sysfs{ifindex}.$sysfs{address}" SUBSYSTEM=="net", PROGRAM="/sbin/biosdevname -i %k --policy=all_names", SYMLINK+="net/by-chassis-id/%c" The following patch will create a device node for network devices based off their ifindex; udev can then use this device node for creating symlinks in /dev/net/xxxx similar to the way that disks now use by-label and by-path symlinks. Combining this with the biosdevname utility and patches to common network utilities, it could be possible to access ethernet devices by their PCI path or BIOS Label. eg. ifconfig Embedded_NIC_1 --- include/linux/major.h~ 2009-07-30 18:34:47.000000000 -0400 +++ include/linux/major.h 2009-08-05 14:52:10.000000000 -0400 @@ -169,6 +169,7 @@ #define IBM_FS3270_MAJOR 228 #define VIOTAPE_MAJOR 230 +#define NETDEV_MAJOR 234 #define BLOCK_EXT_MAJOR 259 #define SCSI_OSD_MAJOR 260 /* open-osd's OSD scsi device */ --- net/core/net-sysfs.cx 2009-08-05 15:00:13.000000000 -0400 +++ net/core/net-sysfs.c 2009-08-05 15:01:20.000000000 -0400 @@ -11,6 +11,7 @@ #include <linux/capability.h> #include <linux/kernel.h> +#include <linux/major.h> #include <linux/netdevice.h> #include <linux/if_arp.h> #include <net/sock.h> @@ -496,6 +497,7 @@ int netdev_register_kobject(struct net_d dev->class = &net_class; dev->platform_data = net; dev->groups = groups; + dev->devt = MKDEV(NETDEV_MAJOR, net->ifindex); BUILD_BUG_ON(BUS_ID_SIZE < IFNAMSIZ); dev_set_name(dev, "%s", net->name); --jordan hargrave Dell Enterprise Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html