| Message ID | 5DDAB7BA7BDB58439DD0EED0B8E9A3AE011CD964@ausx3mpc102.aus.amer.dell.com |
|---|---|
| State | Rejected, archived |
| Delegated to: | David Miller |
| Headers | show |
On Wed, 2009-08-19 at 13:56 -0500, Jordan_Hargrave@Dell.com wrote: > 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 Nice idea, but wouldn't it be "ifconfig LABEL=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); [...] Since this major number is unregistered, the device inode can only be stat'd and not open'd, which seems like a bit of a hack. Is there anything that would stop register_chrdev(0, ...) from allocating this major number, causing network devices to be confused with some other device type? Maybe there *should* be character devices for network device manipulation. It seems like that would avoid the race conditions that device renaming and removal causes for name-based socket ioctls. But maybe everyone should be using netlink for that instead. Ben.
-----Original Message----- From: Ben Hutchings [mailto:bhutchings@solarflare.com] Sent: Wed 8/19/2009 14:26 To: Hargrave, Jordan Cc: netdev@vger.kernel.org; linux-hotplug@vger.kernel.org Subject: Re: PATCH: Network Device Naming mechanism and policy On Wed, 2009-08-19 at 13:56 -0500, Jordan_Hargrave@Dell.com wrote: > 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 Nice idea, but wouldn't it be "ifconfig LABEL=Embedded_NIC_1"? ** Still debating that.. if ifconfig and other tools were smart enough to figure it out ** Right now we have a library that lets you specify it by device node: ** ifconfig /dev/net/by-chassis-id/eth0_s0 for example > --- 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); [...] Since this major number is unregistered, the device inode can only be stat'd and not open'd, which seems like a bit of a hack. Is there anything that would stop register_chrdev(0, ...) from allocating this major number, causing network devices to be confused with some other device type? ** yeah a bit of a hack.. I suppose the netdev code could allocate a ** dynamic major node at startup with register_chrdev.. since nothing ** would use the hardcoded major:minor #s anyway (yet). Maybe there *should* be character devices for network device manipulation. It seems like that would avoid the race conditions that device renaming and removal causes for name-based socket ioctls. But maybe everyone should be using netlink for that instead. Ben.
Jordan_Hargrave@Dell.com wrote: > example udev config: > SUBSYSTEM=="net", SYMLINK+="net/by-mac/$sysfs{ifindex}.$sysfs{address}" So say I have two NICs, currently named eth0/eth1, and I keep them using those names via the current udev MAC address rules. Furthermore, say that this patch is applied, and so I start using 0.<addr0> and 1.<addr1> in my network configuration, instead of eth0/eth1. Now, say that on some given boot, these two NICs show up to the kernel in a different order. I might move them around in the machine (this is, after all, the point behind using the MAC as the identifier ;-) ), or one of them might be USB, or something else random changes the order. With this rule, they're now at 0.<addr1> and 1.<addr0>. In other words, these names are not actually persistent. If you get rid of the $sysfs{ifindex}, then this should work. If that doesn't work for what you're trying to do for some reason, then you can make another directory of symlinks by-ifindex, and use that; that should work as well. But coupling the ifindex to the MAC address like this doesn't work. (In general, coupling any two unrelated attributes when trying to do persistent names doesn't work.)
--- 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);
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 --jordan hargrave Dell Enterprise Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html