Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Andy Gospodarek]

On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote:
> 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.

(Thanks, Bill, though I've been following this thread as I am on the
list).

Right now almost no drivers actually set dev_id.  In fact mlx4_en,
cxgb4, and sfc seem to be the only ones right now.  If we feel like this
a requirement there will be work on the kernel side to add this.

> > 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