Re: Better network naming on Hyper-V/Azure?

[Stephen Hemminger <stephen@xxxxxxxxxxxxxxxxxx>]

On Tue, 7 Jan 2020 19:11:19 +0100
Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:

> On Di, 07.01.20 09:53, Stephen Hemminger (stephen@xxxxxxxxxxxxxxxxxx) wrote:
> 
> > On Tue, 7 Jan 2020 15:01:25 +0100
> > Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
> >  
> > > On Mo, 06.01.20 15:36, Stephen Hemminger (stephen@xxxxxxxxxxxxxxxxxx) wrote:
> > >  
> > > > About a year ago there was some discussion on having persistent network names
> > > > on Hyper-V/Azure. Haiyang did some patches to add an attribute which
> > > > could be used by udev to do this. But there are some reluctance because
> > > > of how the channel id works.
> > > >
> > > > The motivation to provide network naming is to allow vmbus to change to parallel probing.
> > > > Right now probing is serialized so naming is always in same order.
> > > >
> > > > My question is what exactly does systemd/udev need to provide persistent
> > > > naming. The obvious ones are:
> > > >   1. Must be unique (although PCI slot isn't)  
> > >
> > > It's not unique per bus? huh?  
> >
> > If you look in sysfs code, there is already code to handle
> > the case where two devices (usually sub-function) share the same PCI
> > slot. It is handled by adding a suffix in the kernel.  
> 
> For multifunction devices we append an "fXYZ" suffix where XYZ is the
> function index. That should be sufficient, no?
> 
> Lennart

Yes, that works. I was thinking  of case where /sys/bus/pci/slots
can have entries 2 and 2-1 because of duplicates.
See kernel drivers/bus/pci/slot.c:make_slot_name
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel