Patchwork PATCH: Network Device Naming mechanism and policy

login
register
mail settings
Submitter Jordan_Hargrave@Dell.com
Date Aug. 19, 2009, 6:56 p.m.
Message ID <5DDAB7BA7BDB58439DD0EED0B8E9A3AE011CD964@ausx3mpc102.aus.amer.dell.com>
Download mbox | patch
Permalink /patch/31664/
State Rejected
Delegated to: David Miller
Headers show

Comments

Jordan_Hargrave@Dell.com - Aug. 19, 2009, 6:56 p.m.
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
Ben Hutchings - Aug. 19, 2009, 7:26 p.m.
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.
Jordan_Hargrave@Dell.com - Aug. 19, 2009, 7:40 p.m.
-----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.
Bryan Kadzban - Aug. 20, 2009, 4:41 a.m.
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.)

Patch

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