Re: [PATCH] Make ifcfg-eth* NM_CONTROLLED=no work without HWADDR by matching on device name

[Dan Williams <dcbw redhat com>]

On Tue, 2009-05-26 at 18:53 +0100, Marc Herbert wrote:
> Dan Williams a écrit :
> 
> > MAC addresses are used because there are no other unique identifiers.
> > MAC is the only unique identifier, and therefore that's what must be
> > used to match devices.
> 
> OK.
> 
> > Device names change, and therefore are not stable, and therefore cannot
> > be used to provide any type of stable naming.
> 
> Well... it depends, see below.
> 
> > Yes, udev rules can be used to work around some of this problem, but
> > they certainly don't fix everything, and sometimes get it wrong,
> > because there is no possible way for them to get it right 100% of the
> > time.
> 
> You probably mean: for 100% of the hardware?
> 
> > Besides, they use MAC addresses anyway, which means the MAC must be
> > valid for a stable device name provided by udev to exist.
> 
> udev provides a nice abstraction layer providing (user-configurable)
> mappings from obscure and inconvenient hardware identifiers (HWADDR) to
> stable, shorter and much more user-friendly device names (eth1).  So I
> was definitely seeing value in having NM sitting ON TOP OF udev, at
> least for simple Ethernet interfaces. udev rules based on Ethernet MAC
> addresses are certainly stable and right 100% of the time. And I think
> most Linux distributions set them by default at installation.

Except that udev won't always (and shouldn't necessarily) provide stable
device names for every device in your system.  That's not udev sucking;
that's other stuff sucking.  Mainly hardware and kernel stuff.

And if somehow your 75-persistent-net.rules get removed or deleted?
There go all your mappings, and now things are screwed up in ways that
are a lot harder to resolve.  This is also about reducing the number of
cracks that things can fall through.

If you're just going to have udev map HWADDR -> iface, and then NM
depends on iface, why not just have NM use the HWADDR and avoid the
indirection?

> Now please correct if I am wrong: what you say above is that udev sucks
> for other, non-trivial interfaces, right? That is why you do not want NM
> to EVER rely on udev, but rely low-level hardware identifiers like MAC
> addresses instead. OK. So you recommend that NM and udev sit SIDE BY
> SIDE (possibly duplicating HWADDR->names mappings).

I recommend that NM not depend on stable device names at all.  That's
not sitting side-by-side with udev, because NM doesn't really care what
the device name is in the end.  NM doesn't *duplicate* the HWADDR
mappings, because that's simply not how things work.  udev sets up the
mappings, and NM consumes them.  But the difference here is that the
device name is irrelevant in the end, because both NM and udev are using
the same base data: the unique MAC address of the card.

Underneath, the card is defined *solely* by its MAC address.  Every card
on the planet must have a unique MAC address before it can function in a
network with other cards.  Thus, the MAC is the UUID of the card, and
that's a great way to identify the card unqiuely.  So we use it.  So
does udev.

> I suppose that having one less dependency is a benefit for NM. I hope no
> inconsistency problems ever arise from duplicate mappings. Probably no
> big deal. So far so good.
> 
> 
> > If the ifcfg does not have an HWADDR, then there is no possible way to
> > match it up with a real hardware device.  Use udev rules to match on the
> > device's serial number or some other combination of bus IDs to provide a
> > fake MAC if the device doesn't provide one itself.  Then you can use
> > that MAC in the HWADDR field.
> 
> Now this is the part where I am really confused. After having just ruled out
> relying on udev since it sucks for non-trivial interfaces, you now
> ask... udev for help with non-trivial interfaces!?  Thanks
> in advance for clarifying this.

NM does/will rely on udev for other things.  udev doesn't suck.  It's a
great provider of information.

However, what I'm saying is that device names are irrelevant for a
program like NM.  Internally, programs that manipulate network devices
(NM included) use a 'device index', which is what Linux uses internally
to refer to devices.  You don't say "set IP 192.168.1.1 on eth0" to the
kernel, you say "what's the index for eth0?  Ok, set IP 192.168.1.1 on
that index".  *That's* how things actually work.  The device name is an
alias for something else entirely (ie, the index).  Just like device
name is an *alias* for HWADDR.

Again, device names are aliases.  These aliases can change.  HWADDR is
the only unique identifier of the specific network card.  Device names
are not useful internally anyway, they are simply a nice way of letting
the user give a common name to a device at runtime.

Dan