Fedora 15, new and exciting plans (biosdevname)

[Jon Masters]

On Tue, 2010-11-16 at 09:24 -0500, Matthew Miller wrote:
> On Sun, Nov 14, 2010 at 07:53:40AM -0600, Matt Domsch wrote:
> > > > biosdevname installed by default, used in the installer and at runtime
> > > > to rename Dell and HP server onboard NICs from non-deterministic
> > > > "ethX" to clearly labeled "lomX" matching the chassis silkscreen.
> > >   But why ???lomX??? for all? Isn't Lights-Out-Management available only on first
> > > ethernet port and often on dedicated port?
> > This has nothing to do with Lights-Out-Management.  LOM also == LAN on
> > Motherboard.
> 
> Since you're already silkscreening this on the chassis of your systems,
> clearly this ship is well out of the harbor, but that confusion seems like a
> completely legitimate concern. Seems like it could easily result in
> management interfaces getting plugged into the wrong networks.
> 
> Also, I gotta say, it really shouldn't be LAN on Motherboard, since it's
> just an adapter, not actually a whole lan. It should clearly be NIC on
> Motherboard, or "nom". And then you could silkscreen lolcats on to the
> servers, which I think would be a win for everyone.

I've had a few off-list conversations with various community members
about this. One thing that came up was that the alternative namespace is
necessary, but also that "lom" is a sub-optimal choice. One idea that
did come up was simply to call them "net" (net0, etc.) or perhaps "net"
followed by another letter like "netm" or something. To avoid
bikeshedding this to death though, I think Matt's "lom" naming is fine
for the moment unless we happen to all agree on something else.

Meanwhile, there are two other things I'm keeping ticking over:

1). Potential kernel-based solutions to augment this (but not otherwise
affect what would be in F-15). More on that another time.
2). Naming of non-network devices. Both DMTF and other groups (ACPI,
PCI, etc.) looking at the problem of persistent device to slot mappings
have all looked at more than network. While Matt is (rightfully) looking
at networking in F-15, we need to remember this problem actually will in
future also necessitate work on other non-network devices, too.

Jon.