On Tue, 19 Dec 2017 13:55:29 -0800 Jakub Kicinski <kubak...@wp.pl> wrote:
> On Tue, 19 Dec 2017 13:29:49 -0800, Stephen Hemminger wrote: > > > > biosdevname is dead, gone and wouldn't work on Azure (it dumpster > > > > dives in /dev/mem). > > > > > > Hm, I haven't worked on biosdevname myself, but AFAIU it also falls > > > back to information from the PCI VPD, which could be populated by > > > the hypervisor. > > > > VPD never had any useful standard are info. > > The rules used by udev come off sysfs, see: > > > > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ > > > > Yes, the current VPD info looks quite limited, although it is > extendable. > > > > > I assume you mean the modern application is udev, and it works > > > > but the name is meaningless because it based of synthetic PCI > > > > information. The PCI host adapter is simulated for pass through > > > > devices. Names like enp12s0. > > > > > > > > Since every passthrough VF device on Hyper-V/Azure has a matching > > > > synthetic network device with same mac address. It is best to > > > > have the relationship shown in the name. > > > > > > How about we make the VF drivers expose "vf" as phys_port_name? > > > Then systemd/udev should glue that onto the name regardless of > > > how the VF is used. > > > > One of the goals was not to modify in any way other drivers (like VF). > > Why? Do you have out-of-tree drivers you can't change or some such? This needs to work on enterprise distributions; plus it is not good practice to introduce random changes into partners like Mellanox drivers.
