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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <D3F292ADF945FB49B35E96C94C2061B90CEAD321@nsmail.netscout.com>
Date:	Thu, 26 Aug 2010 11:17:51 -0400
From:	"Loke, Chetan" <Chetan.Loke@...scout.com>
To:	"Matt Domsch" <Matt_Domsch@...l.com>,
	"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

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@...r.kernel.org [mailto:netdev-
> owner@...r.kernel.org] On Behalf Of Matt Domsch
> Sent: August 26, 2010 11:01 AM
> To: Stephen Hemminger
> 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 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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ