[PATCH] keep track of network interface renaming

[PATCH] keep track of network interface renaming

[Olaf Hering]

Keep track about which network interface names were renamed after the
network device driver printed its banner. Previous kernel names will
be reused when new interfaces get registerd.
Recent udev scripts implement a stable kernel device name for network
interfaces.
This printk avoids confusion about what network hardware maps to what
kernel interface in later driver or network stack messages.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

---
 net/core/dev.c |    5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

Index: linux-2.6.18-rc4/net/core/dev.c
===================================================================
--- linux-2.6.18-rc4.orig/net/core/dev.c
+++ linux-2.6.18-rc4/net/core/dev.c
@@ -738,8 +738,11 @@ int dev_change_name(struct net_device *d
 	}
 	else if (__dev_get_by_name(newname))
 		return -EEXIST;
-	else
+	else {
+		if (strcmp(newname, dev->name))
+			printk(KERN_INFO "%s renamed to %s\n", dev->name, newname);
 		strlcpy(dev->name, newname, IFNAMSIZ);
+	}
 
 	err = class_device_rename(&dev->class_dev, dev->name);
 	if (!err) {

Re: [PATCH] keep track of network interface renaming

[Patrick McHardy]

Olaf Hering wrote:
> Keep track about which network interface names were renamed after the
> network device driver printed its banner. Previous kernel names will
> be reused when new interfaces get registerd.
> Recent udev scripts implement a stable kernel device name for network
> interfaces.
> This printk avoids confusion about what network hardware maps to what
> kernel interface in later driver or network stack messages.


I think it would be even easier to follow, especially with many devices,
if some stable identifier was included in messages relating to network
devices, like ifindex or maybe the LL address. And it would avoid
spamming the ringbuffer for people making use of this to implement
alternative naming schemes.

2.6.20/2.6.20-rc7 : ethX renumbered

[Paul Rolland]

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

Hello,

I'm facing something quite strange... When booting one of these kernels
(it's a new machine, I've not been running older kernels), the boot message
says :

ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 19 (level, low) -> IRQ 19
sky2 v1.10 addr 0xff8fc000 irq 19 Yukon-EC (0xb6) rev 2
sky2 eth0: addr 00:18:f3:e0:5d:d4
ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 16 (level, low) -> IRQ 16
sky2 v1.10 addr 0xff7fc000 irq 16 Yukon-EC (0xb6) rev 2
sky2 eth1: addr 00:18:f3:e0:36:fd

So, I'm expecting two interfaces : eth0 and eth1

Unfortunately, at the end of the boot process, I can find eth1 and eth2,
something/somewhat/someone has renumbered them ;

eth1      Link encap:Ethernet  HWaddr 00:18:F3:E0:36:FD  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:16 

eth2      Link encap:Ethernet  HWaddr 00:18:F3:E0:5D:D4  
          inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::218:f3ff:fee0:5dd4/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:42780 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25519 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:61859841 (58.9 MiB)  TX bytes:2031644 (1.9 MiB)
          Interrupt:19 

This does also occurs when I boot in single user mode, so I did a quick check
at the processes running then, and found udevd, but there is no reference to
ethX in the configuration files, only veth :
 
root@riri:/Kernels/External# cd /etc/udev/
root@riri:/etc/udev# grep -r eth *
rules.d/90-modprobe.rules:ENV{VIO_TYPE}=="network",
RUN+="/sbin/modprobe -Qba ibmveth"
rules.d/90-modprobe.rules:ENV{VIO_TYPE}=="vlan",
RUN+="/sbin/modprobe -Qba iseries_veth"

Is it something expected ? Or is it because Sky2 is still EXPERIMENTAL ?

Regards,
Paul

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3715 bytes --]

[PATCH] keep track of network interface renaming

[Olaf Hering]

On Sun, Feb 11, Paul Rolland wrote:

> I'm facing something quite strange... When booting one of these kernels
> (it's a new machine, I've not been running older kernels), the boot message
> says :
> 
> ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 19 (level, low) -> IRQ 19
> sky2 v1.10 addr 0xff8fc000 irq 19 Yukon-EC (0xb6) rev 2
> sky2 eth0: addr 00:18:f3:e0:5d:d4
> ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 16 (level, low) -> IRQ 16
> sky2 v1.10 addr 0xff7fc000 irq 16 Yukon-EC (0xb6) rev 2
> sky2 eth1: addr 00:18:f3:e0:36:fd
> 
> So, I'm expecting two interfaces : eth0 and eth1
> 
> Unfortunately, at the end of the boot process, I can find eth1 and eth2,

Unfortunately, this patch was not applied to mainline last year.
Maybe this year.


Keep track about which network interface names were renamed after the
network device driver printed its banner.

Signed-off-by: Olaf Hering <olaf@aepfle.de>

--- linux-2.6.19.orig/net/core/dev.c
+++ linux-2.6.19/net/core/dev.c
@@ -749,7 +749,11 @@ int dev_change_name(struct net_device *d
 	else if (__dev_get_by_name(newname))
 		return -EEXIST;
 	else
+	{
+		if (strncmp(newname, dev->name, IFNAMSIZ))
+			printk(KERN_INFO "%s renamed to %s\n", dev->name, newname);
 		strlcpy(dev->name, newname, IFNAMSIZ);
+	}
 
 	err = class_device_rename(&dev->class_dev, dev->name);
 	if (!err) {

RE: [PATCH] keep track of network interface renaming

[Paul Rolland]

Excellent Olaf !

Yes, I got a "eth0 renamed to eth2".

> Unfortunately, this patch was not applied to mainline last year.
> Maybe this year.

Seconded, you have my vote for this !

Regards,
Paul

Re: [PATCH] keep track of network interface renaming

[David Miller]

From: Olaf Hering <olaf@aepfle.de>
Date: Sun, 11 Feb 2007 13:54:23 +0100

> Keep track about which network interface names were renamed after the
> network device driver printed its banner.
> 
> Signed-off-by: Olaf Hering <olaf@aepfle.de>

This is kernel log clutter.

You can ask the kernel for the list of interfaces, and
use even ethtool to ask what driver each interface is
associated with.

The patch wasn't applied because it really is not necessary.

Re: [PATCH] keep track of network interface renaming

[David Miller]

From: Jason Lunz <lunz@falooley.org>
Date: Sun, 11 Feb 2007 13:27:05 -0500

> On Sun, Feb 11, 2007 at 09:55:52AM -0800, David Miller wrote:
> > This is kernel log clutter.
> > 
> > You can ask the kernel for the list of interfaces, and
> > use even ethtool to ask what driver each interface is
> > associated with.
> > 
> > The patch wasn't applied because it really is not necessary.
> 
> I disagree completely. I'm working right now on a udev-based system that
> does ethernet device renaming. It's quite difficult when working with
> udev to tell exactly when and why each interface was renamed, since it's
> typically done within initramfs where it's difficult to enable debug
> messages. This printk helps immensely.

You can listen on a netlink socket for these events if you
want to see when they occur.

There is no need for this log message, it is superfluous.

Re: [PATCH] keep track of network interface renaming

[Tilman Schmidt]

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

Am 11.02.2007 19:28 schrieb David Miller:
> From: Jason Lunz <lunz@falooley.org>
> Date: Sun, 11 Feb 2007 13:27:05 -0500
> 
>> On Sun, Feb 11, 2007 at 09:55:52AM -0800, David Miller wrote:
>>> This is kernel log clutter.
>>>
>>> You can ask the kernel for the list of interfaces, and
>>> use even ethtool to ask what driver each interface is
>>> associated with.
>>>
>>> The patch wasn't applied because it really is not necessary.
>> I disagree completely. I'm working right now on a udev-based system that
>> does ethernet device renaming. It's quite difficult when working with
>> udev to tell exactly when and why each interface was renamed, since it's
>> typically done within initramfs where it's difficult to enable debug
>> messages. This printk helps immensely.
> 
> You can listen on a netlink socket for these events if you
> want to see when they occur.
> 
> There is no need for this log message, it is superfluous.

I disagree. This message can be very helpful. The problem of network
interfaces being renamed is a real and frequent one. A single message
per interface is tolerable even if you don't actually need it. My
kernel log currently produces well over 400 messages per boot, so if
you want to reduce kernel log clutter, there are lots of other
candidates.

-- 
Tilman Schmidt                          E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]

Re: [PATCH] keep track of network interface renaming

[Robert Hancock]

David Miller wrote:
> From: Jason Lunz <lunz@falooley.org>
> Date: Sun, 11 Feb 2007 13:27:05 -0500
> 
>> On Sun, Feb 11, 2007 at 09:55:52AM -0800, David Miller wrote:
>>> This is kernel log clutter.
>>>
>>> You can ask the kernel for the list of interfaces, and
>>> use even ethtool to ask what driver each interface is
>>> associated with.
>>>
>>> The patch wasn't applied because it really is not necessary.
>> I disagree completely. I'm working right now on a udev-based system that
>> does ethernet device renaming. It's quite difficult when working with
>> udev to tell exactly when and why each interface was renamed, since it's
>> typically done within initramfs where it's difficult to enable debug
>> messages. This printk helps immensely.
> 
> You can listen on a netlink socket for these events if you
> want to see when they occur.

Unfortunately that's not very practical if, as in this case, the 
renaming is being done from an initramfs. Hiding this information as we 
do now is rather user-hostile.

> 
> There is no need for this log message, it is superfluous.

I think the minimal extra output from this is well worth it. If we care 
so much about limiting dmesg output, how about getting rid of all those 
hundreds of "PM: Adding info for" messages in recent kernels..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: [PATCH] keep track of network interface renaming

[David Miller]

From: Robert Hancock <hancockr@shaw.ca>
Date: Sun, 11 Feb 2007 13:20:10 -0600

> Unfortunately that's not very practical if, as in this case, the 
> renaming is being done from an initramfs. Hiding this information as we 
> do now is rather user-hostile.

Perhaps you have a point, I'll think about this some more.

But on the other hand note that kernel log messages can scroll away
and get lost, so you cannot really rely upon them for gathering
information which is necessary for properly detecting devices
in userspace or anything like that.