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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

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

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel