RE: [PATCH] Add firmware label support to iproute2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx [mailto:netdev-
> owner@xxxxxxxxxxxxxxx] On Behalf Of Matt Domsch
> Sent: August 26, 2010 11:01 AM
> To: Stephen Hemminger
> Cc: Narendra_K@xxxxxxxx; netdev@xxxxxxxxxxxxxxx;
Charles_Rose@xxxxxxxx;
> Jordan_Hargrave@xxxxxxxx; linux-pci@xxxxxxxxxxxxxxx; linux-
> hotplug@xxxxxxxxxxxxxxx
> 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=125522163322610&w=2 (Marco
> d'Itri)
> [2] http://marc.info/?l=linux-hotplug&m=123793549323431&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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux