On Wed, Apr 4, 2018 at 10:37 AM, David Miller <davem@xxxxxxxxxxxxx> wrote: > From: David Ahern <dsahern@xxxxxxxxx> > Date: Wed, 4 Apr 2018 11:21:54 -0600 > >> It is a netdev so there is no reason to have a separate ip command to >> inspect it. 'ip link' is the right place. > > I agree on this. I'm completely fine of having an API for inspection purpose. The thing is that we'd perhaps need to go for the namespace approach, for which I think everyone seems to agree not to fiddle with the ":" prefix, but rather have a new class of network subsystem under /sys/class thus a separate device namespace e.g. /sys/class/net-kernel for those auto-managed lower netdevs is needed. And I assume everyone here understands the use case for live migration (in the context of providing cloud service) is very different, and we have to hide the netdevs. If not, I'm more than happy to clarify. With that in mind, if having a new class of net-kernel namespace, we can name the kernel device elaborately which is not neccessarily equal to the device name exposed to userspace. For example, we can use driver name as the prefix as opposed to "eth" or ":eth". And we don't need to have auto-managed netdevs locked into the ":" prefix at all (I intentionally left it out in the this RFC patch to ask for comments on the namespace solution which is much cleaner). That said, an userpsace named device through udev may call something like ens3 and switch1-port2, but in the kernel-net namespace, it may look like ixgbevf0 and mlxsw1p2. So if we all agree introducing a new namespace is the rigth thing to do, `ip link' will no longer serve the purpose of displaying the information for kernel-net devnames for the sake of avoiding ambiguity and namespace collision: it's entirely possible the ip link name could collide with a kernel-net devname, it's become unclear which name of a netdev object the command is expected to operate on. That's why I thought showing the kernel-only netdevs using a separate subcommand makes more sense. Thoughts and comments? Please let me know. Thanks, -Siwei > > What I really don't understand still is the use case... really. > > So there are control netdevs, what exactly is the problem with that? > > Are we not exporting enough information for applications to handle > these devices sanely? If so, then's let add that information. > > We can set netdev->type to ETH_P_LINUXCONTROL or something like that. > > Another alternative is to add an interface flag like IFF_CONTROL or > similar, and that probably is much nicer. > > Hiding the devices means that we acknowledge that applications are > currently broken with control netdevs... and we want them to stay > broken! > > That doesn't sound like a good plan to me. > > So let's fix handling of control netdevs instead of hiding them. > > Thanks. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
