Re: [PATCH v5 0/4] Provide netdev naming-policy via sysfs

[David Herrmann]

Hi

On Fri, Mar 28, 2014 at 7:54 PM, David Miller <davem@xxxxxxxxxxxxx> wrote:
> udev can look at the device type, and policies can be defined that key
> off of that device type, entirely in userspace.

Regarding wifi-P2P devices, udev can indeed use nl80211 to get the
exact IF-type. An attribute would be much easier to read out, but I'm
ok if we don't want to replicate that information.

However, as mentioned in the discussions on v1, there're more
use-cases than that. Imagine a 3rd party initrd renames a
network-device early, if udev runs in the main system, we would rename
the device again. If we could detect the rename via NET_NAME_RENAMED,
we wouldn't break such setups. The only reason to rename devices in
udev is to get reliable names. If someone else already renamed a
device, we always expect them to provide better names than we do, so
udev should only touch devices that have kernel-enumerated names.
Of course, this can be fixed by requiring all the initrd developers to
somehow tag devices as already renamed. But this would replicate
information that the kernel already has.

Another example are dynamically created devices via RTM_NEWLINK. The
if-names are provided by user-space and udev should never try to do
any magic renaming on them (why would we? you can just easily fix the
code that created the device).

So it turns out, all we want to know is whether an interface-name was
chosen by the kernel via plain, simple enumeration, or whether it has
a user-space origin. Only in the former case we want to rename the
device. The name_assign_type attribute tells us exactly where a name
comes from and thus avoids maintaining blacklists in user-space that
skip renaming on such devices. I'm sorry, but I cannot see why such
blacklists (or whitelists) are preferred over a sysfs attribute.

Thanks
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/