On Mon, 9 Apr 2018 15:30:42 -0700 Siwei Liu <loseweigh@xxxxxxxxx> wrote: > 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 Also, remember for netdev's /sys is really a third class API. The primary API's are netlink and ioctl. Also why not use existing network namespaces rather than inventing a new abstraction? _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
