netdev - Re: [PATCH] Add firmware label support to iproute2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100826163855.GA6774@auslistsprd01.us.dell.com>
Date:	Thu, 26 Aug 2010 11:38:55 -0500
From:	Matt Domsch <Matt_Domsch@...l.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	Narendra_K@...l.com, netdev@...r.kernel.org, Charles_Rose@...l.com,
	Jordan_Hargrave@...l.com, linux-pci@...r.kernel.org,
	linux-hotplug@...r.kernel.org
Subject: Re: [PATCH] Add firmware label support to iproute2

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html