On Mon, Apr 9, 2018 at 3:15 PM, Andrew Lunn <andrew@xxxxxxx> wrote: >> No, implementation wise I'd avoid changing the class on the fly. What >> I'm looking to is a means to add a secondary class or class aliasing >> mechanism for netdevs that allows mapping for a kernel device >> namespace (/class/net-kernel) to userspace (/class/net). Imagine >> creating symlinks between these two namespaces as an analogy. All >> userspace visible netdevs today will have both a kernel name and a >> userspace visible name, having one (/class/net) referecing the other >> (/class/net-kernel) in its own namespace. The newly introduced >> IFF_AUTO_MANAGED device will have a kernel name only >> (/class/net-kernel). As a result, the existing applications using >> /class/net don't break, while we're adding the kernel namespace that >> allows IFF_AUTO_MANAGED devices which will not be exposed to userspace >> at all. > > My gut feeling is this whole scheme will not fly. You really should be > talking to GregKH. Will do. Before spreading it out loudly I'd run it within netdev to clarify the need for why not exposing the lower netdevs is critical for cloud service providers in the face of introducing a new feature, and we are not hiding anything but exposing it in a way that don't break existing userspace applications while introducing feature is possible with the limitation of keeping old userspace still. > > Anyway, please remember that IFF_AUTO_MANAGED will need to be dynamic. > A device can start out as a normal device, and will change to being > automatic later, when the user on top of it probes. Sure. In whatever form it's still a netdev, and changing the namespace should be more dynamic than changing the class. Thanks a lot, -Siwei > > Andrew _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
