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

[Marc Herbert <Marc Herbert gmail com>]

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.

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 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.

Cheers,

Marc