using udev for network devices?

using udev for network devices?

[Arnd Bergmann]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

The attached patch adds code to use the SIOCSIFNAME ioctl
for naming network devices from udev. This is a solution to
the problem of persisting naming for network devices that
don't have a MAC address. The problem is very common for
virtual network devices on s390, but I'm sure others have it
as well.

Note that this is just proof-of-concept. The code is missing
some checks and I'm not sure if udev is the right place
to this (maybe an libsysfs'ified extended nameif or a new 
tool might be better).

Opinions?

        Arnd <><

[-- Attachment #2: netudev.diff --]
[-- Type: text/plain, Size: 1915 bytes --]

===== udev-add.c 1.42 vs edited =====
--- 1.42/udev-add.c	Sat Jan 17 16:39:00 2004
+++ edited/udev-add.c	Fri Jan 23 00:41:02 2004
@@ -27,6 +27,9 @@
 #include <fcntl.h>
 #include <unistd.h>
 #include <errno.h>
+#include <net/if.h>
+#include <sys/ioctl.h>
+#include <sys/socket.h>
 #include <sys/stat.h>
 #include <sys/types.h>
 #include <grp.h>
@@ -245,6 +248,26 @@
 	return retval;
 }
 
+static int name_netdevice(struct udevice *dev)
+{
+	int fd;
+	int retval;
+	struct ifreq ifr;
+
+	strncpy(ifr.ifr_name, dev->kernel_name, IFNAMSIZ);
+	strncpy(ifr.ifr_newname, dev->name, IFNAMSIZ);
+
+	fd = socket(PF_INET, SOCK_DGRAM, 0);
+	if (fd == -1)
+		return errno;
+
+	retval = ioctl(fd, SIOCSIFNAME, &ifr);
+	
+	close(fd);
+
+	return retval;
+}
+
 static struct sysfs_class_device *get_class_dev(char *device_name)
 {
 	char dev_path[SYSFS_PATH_MAX];
@@ -310,15 +333,23 @@
 	else
 		dev.type = 'c';
 
-	retval = sleep_for_dev(path);
-	if (retval)
-		goto exit;
-
 	class_dev = get_class_dev(path);
 	if (class_dev == NULL)
 		goto exit;
 
-	retval = get_major_minor(class_dev, &dev);
+	if (strcmp(class_dev->classname, "net") == 0) {
+		dev.type = 'n';
+		retval = 0;
+	} else {
+		retval = sleep_for_dev(path);
+	}
+
+	if (retval)
+		goto exit;
+
+	if (dev.type != 'n')
+		retval = get_major_minor(class_dev, &dev);
+
 	if (retval) {
 		dbg("get_major_minor failed");
 		goto exit;
@@ -334,7 +365,10 @@
 		    "But remove might not work properly for this device.");
 
 	dbg("name='%s'", dev.name);
-	retval = create_node(&dev);
+	if (dev.type == 'n')
+		retval = name_netdevice(&dev);
+	else
+		retval = create_node(&dev);
 
 	if (retval == 0)
 		sysbus_send_create(&dev, path);
===== udev.c 1.38 vs edited =====
--- 1.38/udev.c	Sat Jan 17 15:47:18 2004
+++ edited/udev.c	Fri Jan 23 00:56:15 2004
@@ -279,7 +279,6 @@
 }
 
 static char *subsystem_blacklist[] = {
-	"net",
 	"scsi_host",
 	"scsi_device",
 	"usb_host",

Re: using udev for network devices?

[Greg KH]

On Fri, Jan 23, 2004 at 01:06:01AM +0100, Arnd Bergmann wrote:
> The attached patch adds code to use the SIOCSIFNAME ioctl
> for naming network devices from udev. This is a solution to
> the problem of persisting naming for network devices that
> don't have a MAC address. The problem is very common for
> virtual network devices on s390, but I'm sure others have it
> as well.
> 
> Note that this is just proof-of-concept. The code is missing
> some checks and I'm not sure if udev is the right place
> to this (maybe an libsysfs'ified extended nameif or a new 
> tool might be better).

Nice patch, but I really think that a libsysfs'ified version of nameif
would be the better place for this.

I also think there are some Nokia people with some patches to nameif
that do much the same thing (but I think they rely on pci ids.)

But if the nameif maintainers, and the network developers think that
udev is an approiate tool to name network devices, I could be
convinced... 

thanks,

greg k-h


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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