Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Bill Nottingham]

Matt Domsch (Matt_Domsch at dell.com) said: 
> On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote:
> > > If we can solve the installtime naming convention choice to not
> > > eliminate biosdevname, be able to disable systemd/udevd naming, and
> > > have the default be possible on a per-system-vendor basis, and solve
> > > the NPAR/SR-IOV/Mellanox naming problems, then I can support this
> > > proposal.  Without fixing these shortcomings though, my customers will
> > > have a fit at me.
> > 
> > If you're agreeing that biosdevname should be limited to type9/type41
> > (if I'm reading you right), and if the systemd/udev names still use those
> > fields, what parts of biosdevname are you still requiring? The actual
> > namespace used, or something else?
> 
> I'd prefer if we didn't force users through another namespace change.
> I took a lot of flack for changing the namespace once.  From their
> perspective, it's still udev doing the renaming, only now the code
> moved from a udev helper into udev itself.

True; the users likely don't care other than how they enable/disable it.

> I'd like to see the SR-IOV & NPAR devices handled.  Those aren't
> represented in type9/type41, and their commonplace on Dell systems.
> 
> I'd like to see the Dell-specific PCI VPD-R code from biosdevname
> included in udev, as that's used to map multi-port devices to port
> numbers.  Those aren't represented in type9/type41, and they're
> commonplace on Dell systems.

OK.

> I'd like to see kernel driver work to be sure every multi-port driver
> with the same PCI b/d/b/f sets dev_id.  That isn't necessarily true
> today, which makes it hard to trust.  biosdevname needs this too,
> until such a time as it's dead.

Do we have a list of these, or is it a matter of doing a driver audit?
CC'ing gospo.

> So, aside from the naming convention change (which, hey, if someone
> else takes the pain for making that change again, not me or my company
> - go nuts!), the rest is straightforward technical and code can be
> cribbed if desired from biosdevname or just rewritten.

OK, thanks. Let's see what we can do here. My concern is the conflict
between trying to cover all of the cases, and trying to avoid writing
documentation that is a lot of "if your device is <hereh>, then your
name is Y or Z depending on which commandline you booted with when you
installed.'

Bill