Proposed F19 Feature: systemd/udev Predictable Network Interface Names

[Matt Domsch]

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.

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.

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.


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.

Thanks,
Matt


-- 
Matt Domsch
Technology Strategist
Dell | Office of the CTO