On Wed, Feb 27, 2019 at 04:03:42PM -0800, Stephen Hemminger wrote: > > With this approach kernel will deny attempts by userspace to rename > > slaves. Slaves will always be named XXXnsby and XXnpry. Master renames > > will rename both slaves. > > > > It seems pretty solid to me, the only issue is that in theory userspace > > can use a name like XXXnsby for something else. But this seems unlikely. > > Similar schemes (with kernel providing naming) were also previously rejected > upstream. Links? I'm inclined to try and see what happens. > It has been a consistent theme that the kernel should not be in > the renaming business. In this case it's not in renaming business per se. The only reason we even have the original name is due to the ways internal APIs work. You can look at it as simply having slaves names being part of master. > It will certainly break userspace. That's a strong claim. What is it based on? It so happens that userspace renaming slaves is already broken on virtio. So we can fix it any way we like :) And yes it won't help netvsc because netvsc wants compatibility with old scripts but then netvsc uses a 2 device model anyway. -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
