Dan Williams wrote:
quoted text
> On Tue, 2009-03-24 at 17:21 +0100, Patrick McHardy wrote:
>> I would classify this as a bug, especially the fact that udev doesn't
>> undo a failed rename, so you end up with ethX_rename. Virtual devices
>> using the same MAC address trigger this reliably unless you add
>> exceptions to the udev rules.
> 
> Any particular reason the MAC addresses are the same?  This came up a
> while ago with the 'dnet' device in the thread "Dave DNET ethernet
> controller".
> 
> If the MAC address isn't a UUID for the device, then *what* is?

Sometimes (I was referring to virtual devices) there may not be
one, thats correct.

quoted text
> If there isn't one, then certainly udev can't be blamed for getting
> ordering or names wrong, because there's nothing to use to actually
> match up the device to a name, uniquely. 

I agree that udev can't do anything useful in that case. I would
prefer it it wouldn't even try though instead of messing with the
names and leaving a bunch of _rename devices around. Sure, I can
add a rule to disable it, but that shouldn't be necessary.

Generally, I'm wondering whether it should touch virtual network
devices at all since the MAC addresses are often not persistent,
sometimes not unique and the name might have already been chosen
explicitly by the administrator when creating the device.

Currently there are some rules to ignore a couple of known virtual
devices types. Are there actually cases where renaming virtual
devices is desired? Otherwise a more future-proof way than
blacklisting each type individually would be to add some attribute
informing udev that the device has no unique key and should be
ignored.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html