Re: [PATCH] Add firmware label support to iproute2

Re: [PATCH] Add firmware label support to iproute2

[Matt Domsch]

On Wed, Aug 25, 2010 at 05:16:46PM -0700, Stephen Hemminger wrote:
> On Wed, 25 Aug 2010 17:03:23 -0500
On Wed, Aug 25, 2010 at 05:16:46PM -0700, Stephen Hemminger wrote:
> Is it really a good idea to have to change every utility that could
> alter network devices?  There is iproute2, iputils, tcpdump, wireshark,
> quagga, snmp, ...  Many of the utilities come from a BSD world,
> and will be less likely to accept some Linux specific wart.

I agree, I don't want to have to change all those userspace apps
either.  We've started creating patches and are willing to do so if it
will yield the result we want though.
 
> I have lost faith in this library wrapper support everywhere method.
> Let's just keep the firmware stuff in udev. If the user wants to
> have a policy that renames device from eth0 to "Embedded BIOS LAN1" then
> do it in udev. Or if you want to keep the ethX naming convention
> and stuff the firmware label into ifAlias or other sysfs field
> so it can be displayed that will be not a big issue.

1) we remain constrained to IFNAMSIZ named arguments.  There is no
   such constraint on BIOS-provided names.  Dell BIOS presently uses
   'Embedded NIC 1' which (fortunately) is 14 chars. We're cutting it
   awfully close already.  I can't dictate to non-Dell BIOS vendors
   what to use as their strings, or how long to make them.

digression 1a) udev has a replace-spaces-with-underscores feature I used in
    the biosdevname udev rules.  That's a reasonable munging of the
    provided strings.  Much more than that and I'm not sure we could
    consistently get it right.

2) there are apps which use a regexp for device names.  We'd have to
   find and fix those too.  Arguably we'd have to do this when we
   patch them to use libnetdevname. [1]

3) it continues to force a single naming convention for NICs, where
   for other types of devices we can have several independent naming
   conventions.  I have end users who wish to name their interfaces by
   the BIOS label, others by the function (public, dmz,
   backup, storage, ...) that the network segment provides.  While we
   could have different policies, each system can have only one policy
   at a time.
  

David Miller had suggested [2] that we could add a method to get
alternate labels for devices by querying them.  We've got something
similar now by exporting the labels for devices in sysfs.  Yea -
progress!

But we can't _use_ those labels for more than display
(meaning a human is doing the mapping in their heads), or to rename
devices.  We can't use the labels in scripts without doing the label->kernel
name lookups, and then using the kernel name.

I'm open to revisiting the "have udev rename devices", but I tried
that with biosdevname 2 years ago, with little success.  Adding in the
hotplug dev team to the thread.


[1] http://marc.info/?l=linux-netdev&m\x125522163322610&w=2 (Marco d'Itri)
[2] http://marc.info/?l=linux-hotplug&m\x123793549323431&w=2

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO

RE: [PATCH] Add firmware label support to iproute2

[Loke, Chetan]

What if we extend 'IFNAMSIZ'(beyond 16 chars. Older apps don't need to
worry because they have been working w/ 16 chars anyways) and also get
ifalias to work in udev(Or is ifalias a bad idea?)?

Chetan

> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of Matt Domsch
> Sent: August 26, 2010 11:01 AM
> To: Stephen Hemminger
> Cc: Narendra_K@Dell.com; netdev@vger.kernel.org;
Charles_Rose@Dell.com;
> Jordan_Hargrave@Dell.com; linux-pci@vger.kernel.org; linux-
> hotplug@vger.kernel.org
> Subject: Re: [PATCH] Add firmware label support to iproute2
> 
> On Wed, Aug 25, 2010 at 05:16:46PM -0700, Stephen Hemminger wrote:
> > On Wed, 25 Aug 2010 17:03:23 -0500
> On Wed, Aug 25, 2010 at 05:16:46PM -0700, Stephen Hemminger wrote:
> > Is it really a good idea to have to change every utility that could
> > alter network devices?  There is iproute2, iputils, tcpdump,
> wireshark,
> > quagga, snmp, ...  Many of the utilities come from a BSD world,
> > and will be less likely to accept some Linux specific wart.
> 
> I agree, I don't want to have to change all those userspace apps
> either.  We've started creating patches and are willing to do so if it
> will yield the result we want though.
> 
> > I have lost faith in this library wrapper support everywhere method.
> > Let's just keep the firmware stuff in udev. If the user wants to
> > have a policy that renames device from eth0 to "Embedded BIOS LAN1"
> then
> > do it in udev. Or if you want to keep the ethX naming convention
> > and stuff the firmware label into ifAlias or other sysfs field
> > so it can be displayed that will be not a big issue.
> 
> 1) we remain constrained to IFNAMSIZ named arguments.  There is no
>    such constraint on BIOS-provided names.  Dell BIOS presently uses
>    'Embedded NIC 1' which (fortunately) is 14 chars. We're cutting it
>    awfully close already.  I can't dictate to non-Dell BIOS vendors
>    what to use as their strings, or how long to make them.
> 
> digression 1a) udev has a replace-spaces-with-underscores feature I
> used in
>     the biosdevname udev rules.  That's a reasonable munging of the
>     provided strings.  Much more than that and I'm not sure we could
>     consistently get it right.
> 
> 2) there are apps which use a regexp for device names.  We'd have to
>    find and fix those too.  Arguably we'd have to do this when we
>    patch them to use libnetdevname. [1]
> 
> 3) it continues to force a single naming convention for NICs, where
>    for other types of devices we can have several independent naming
>    conventions.  I have end users who wish to name their interfaces by
>    the BIOS label, others by the function (public, dmz,
>    backup, storage, ...) that the network segment provides.  While we
>    could have different policies, each system can have only one policy
>    at a time.
> 
> 
> David Miller had suggested [2] that we could add a method to get
> alternate labels for devices by querying them.  We've got something
> similar now by exporting the labels for devices in sysfs.  Yea -
> progress!
> 
> But we can't _use_ those labels for more than display
> (meaning a human is doing the mapping in their heads), or to rename
> devices.  We can't use the labels in scripts without doing the label-
> >kernel
> name lookups, and then using the kernel name.
> 
> I'm open to revisiting the "have udev rename devices", but I tried
> that with biosdevname 2 years ago, with little success.  Adding in the
> hotplug dev team to the thread.
> 
> 
> [1] http://marc.info/?l=linux-netdev&m\x125522163322610&w=2 (Marco
> d'Itri)
> [2] http://marc.info/?l=linux-hotplug&m\x123793549323431&w=2
> 
> --
> Matt Domsch
> Technology Strategist
> Dell | Office of the CTO
> --
> 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

Re: [PATCH] Add firmware label support to iproute2

[Stephen Hemminger]

On Thu, 26 Aug 2010 11:17:51 -0400
"Loke, Chetan" <Chetan.Loke@netscout.com> wrote:

> What if we extend 'IFNAMSIZ'(beyond 16 chars. Older apps don't need to
> worry because they have been working w/ 16 chars anyways) and also get
> ifalias to work in udev(Or is ifalias a bad idea?)?
> 
> Chetan
>
That is  non-starter for the ioctl() style interface.

struct ifreq {
#define IFHWADDRLEN	6
	union
	{
		char	ifrn_name[IFNAMSIZ];		/* if name, e.g. "en0" */
	} ifr_ifrn;
	
	union {
		struct	sockaddr ifru_addr;
		struct	sockaddr ifru_dstaddr;
		struct	sockaddr ifru_broadaddr;
		struct	sockaddr ifru_netmask;
		struct  sockaddr ifru_hwaddr;
		short	ifru_flags;
		int	ifru_ivalue;
		int	ifru_mtu;
		struct  ifmap ifru_map;
		char	ifru_slave[IFNAMSIZ];	/* Just fits the size */
		char	ifru_newname[IFNAMSIZ];
		void __user *	ifru_data;
		struct	if_settings ifru_settings;
	} ifr_ifru;
};

Applications do:
   	strncpy(ifr.ifr_name, "my name", IFNAMSIZ);
	ioctl(fd, SIOCGHWADDR, &ifr)

RE: [PATCH] Add firmware label support to iproute2

[Loke, Chetan]

Sorry, my bad.
I agree w/ your recommendation then - 
1) stuff it in ifalias(or create a new alias if net_device::ifalias is
used for snmp etc).

But how do we consume it? 
   1.1) spit it out via sysfs? But Doc/sysfsrules.txt says "Accessing
/sys/class/net/eth0/device is a bug in the application"


Chetan

> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> Sent: August 26, 2010 11:22 AM
> To: Loke, Chetan
> Cc: Matt Domsch; Narendra_K@Dell.com; netdev@vger.kernel.org;
> Charles_Rose@Dell.com; Jordan_Hargrave@Dell.com; linux-
> pci@vger.kernel.org; linux-hotplug@vger.kernel.org
> Subject: Re: [PATCH] Add firmware label support to iproute2
> 
> On Thu, 26 Aug 2010 11:17:51 -0400
> "Loke, Chetan" <Chetan.Loke@netscout.com> wrote:
> 
> > What if we extend 'IFNAMSIZ'(beyond 16 chars. Older apps don't need
> to
> > worry because they have been working w/ 16 chars anyways) and also
> get
> > ifalias to work in udev(Or is ifalias a bad idea?)?
> >
> > Chetan
> >
> That is  non-starter for the ioctl() style interface.
> 
> struct ifreq {
> #define IFHWADDRLEN	6
> 	union
> 	{
> 		char	ifrn_name[IFNAMSIZ];		/* if name, e.g.
"en0"
> */
> 	} ifr_ifrn;
> 
> 	union {
> 		struct	sockaddr ifru_addr;
> 		struct	sockaddr ifru_dstaddr;
> 		struct	sockaddr ifru_broadaddr;
> 		struct	sockaddr ifru_netmask;
> 		struct  sockaddr ifru_hwaddr;
> 		short	ifru_flags;
> 		int	ifru_ivalue;
> 		int	ifru_mtu;
> 		struct  ifmap ifru_map;
> 		char	ifru_slave[IFNAMSIZ];	/* Just fits the size */
> 		char	ifru_newname[IFNAMSIZ];
> 		void __user *	ifru_data;
> 		struct	if_settings ifru_settings;
> 	} ifr_ifru;
> };
> 
> Applications do:
>    	strncpy(ifr.ifr_name, "my name", IFNAMSIZ);
> 	ioctl(fd, SIOCGHWADDR, &ifr)

Re: [PATCH] Add firmware label support to iproute2

[Matt Domsch]

On Thu, Aug 26, 2010 at 10:01:16AM -0500, Matt Domsch wrote:
> On Wed, Aug 25, 2010 at 05:16:46PM -0700, Stephen Hemminger wrote:
> > On Wed, 25 Aug 2010 17:03:23 -0500
> On Wed, Aug 25, 2010 at 05:16:46PM -0700, Stephen Hemminger wrote:
> > Is it really a good idea to have to change every utility that could
> > alter network devices?  There is iproute2, iputils, tcpdump, wireshark,
> > quagga, snmp, ...  Many of the utilities come from a BSD world,
> > and will be less likely to accept some Linux specific wart.
> 
> I agree, I don't want to have to change all those userspace apps
> either.  We've started creating patches and are willing to do so if it
> will yield the result we want though.
>  
> > I have lost faith in this library wrapper support everywhere method.
> > Let's just keep the firmware stuff in udev. If the user wants to
> > have a policy that renames device from eth0 to "Embedded BIOS LAN1" then
> > do it in udev. Or if you want to keep the ethX naming convention
> > and stuff the firmware label into ifAlias or other sysfs field
> > so it can be displayed that will be not a big issue.
> 
> 1) we remain constrained to IFNAMSIZ named arguments.  There is no
>    such constraint on BIOS-provided names.  Dell BIOS presently uses
>    'Embedded NIC 1' which (fortunately) is 14 chars. We're cutting it
>    awfully close already.  I can't dictate to non-Dell BIOS vendors
>    what to use as their strings, or how long to make them.

vlan usage requires 5 characters from IFNAMSIZ (eth0.4095).  So my
example with 'Embedded NIC 1' plus a vlan doesn't fit.

-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO

Re: [PATCH] Add firmware label support to iproute2

[Kay Sievers]

On Thu, Aug 26, 2010 at 17:38, Loke, Chetan <Chetan.Loke@netscout.com> wrote:
> Sorry, my bad.
> I agree w/ your recommendation then -
> 1) stuff it in ifalias(or create a new alias if net_device::ifalias is
> used for snmp etc).
>
> But how do we consume it?
>   1.1) spit it out via sysfs? But Doc/sysfsrules.txt says "Accessing
> /sys/class/net/eth0/device is a bug in the application"

You walk up the parent devices of the netdev until you find the one
you are looking for. The "device" link is broken by design and might
just point to the first parent device. The kernel is free to insert
devices into the device tree if needed, and then the device link
target may change.

/sys/class/net/eth0 is a symlink pointing to a location the
/sys/devices tree, like:
  ../../devices/pci0000:00/0000:00:19.0/net/eth0
One of the parent devices of the eth0 device has this attribute., but
you can never be sure that it's just the next parent (broken concept
of the device link), you have to walk up the chain of parents.

You can just use udev to that automatically and extract the value, and
pass it with the event for the eth0 device.

Kay