Date:	Sat, 10 Oct 2009 10:34:16 -0700
From:	Bryan Kadzban <bryan@...zban.is-a-geek.net>
To:	Greg KH <greg@...ah.com>
CC:	Matt Domsch <Matt_Domsch@...l.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	netdev@...r.kernel.org, linux-hotplug@...r.kernel.org,
	Narendra_K@...l.com, jordan_hargrave@...l.com
Subject: Re: PATCH: Network Device Naming mechanism and policy

Greg KH wrote:
> On Sat, Oct 10, 2009 at 07:47:32AM -0500, Matt Domsch wrote:
>> On Fri, Oct 09, 2009 at 10:23:08PM -0700, Greg KH wrote:
>>> On Fri, Oct 09, 2009 at 11:40:57PM -0500, Matt Domsch wrote:
>>>> The fundamental roadblock to this is that enumeration !=
>>>> naming, except that it is for network devices, and we keep
>>>> changing the enumeration order.
>>> No, the hardware changes the enumeration order, it places _no_ 
>>> guarantees on what order stuff will be found in.  So this is not
>>> the kernel changing, just to be clear.
>> Over time the kernel has changed its enumeration mechanisms, and 
>> introduced parallelism into the process (which is a good thing), 
>> which, from a user perspective, makes names nondeterministic.  Yes,
>> fixing this up by hard-coding MAC addresses after install has been
>> the traditional mechanism to address this.  I think there's a
>> better way.
> 
> Ok, but that way can be done in userspace, without the need for this 
> char device, right?

For the record -- when I tried to send a patch that did exactly this
(provided an option to use by-path persistence for network drivers), it
was rejected because "that doesn't work for USB".

True, it doesn't.  But by-mac (what we have today) doesn't work for
replacing motherboards in a random home system (that can't override the
MAC address in the BIOS), either.

So why not provide both alternatives?

As you say below, it's up to the network devs whether this should be
allowed...

>> biosdevname can be used in udev rules to create multiple names for
>> a given device.  Rules such as:
> 
> Yes, if you want multiple ways to name a network device, then you
> need the char nodes.  But without that, you can just pick "always use
> the biosdevname" type option from your distro setup screen and go
> with that. Then you have everything always working properly from the
> very beginning.

*If* biosdevname works on your system.  It doesn't on mine: this SMBIOS
extension doesn't exist.  :-)

> So you really want this for multiple ways to name the same network 
> device.  That's a choice the network developers are going to have to 
> make, as to if that is going to be a legal thing to have happen or
> not.

Yes.  So do I, actually (for what little that's worth)...

> But this code is not a requirement to "solve" the fact that network 
> devices can show up in different order, that problem can be solved as
> long as the user picks a single way to name the devices, using tools
> that are already present today in distros.

This code is not a requirement, no.  But -- as you say -- it does
provide a halfway-decent way to assign multiple names to a NIC.  And
that provides admins the choice to use a couple different persistence
schemes, depending on how they expect their hardware to work.

(It *may* even be possible to use some kind of layer-2 traffic to see
what else is on the connected network and provide symlinks based on
that.  IPv6 autoconfig type of thing, maybe.  That's probably a *lot*
more complicated, and may be impossible, but would be even closer to
what I think Dell customers are asking for based on Matt's posts.)


Download attachment "signature.asc" of type "application/pgp-signature" (261 bytes)

Powered by blists - more mailing lists