[systemd-devel] Network Interface Names: solution for a desktop OS

[Xen]

Greg KH schreef op 11-04-16 01:05:
> On Mon, Apr 11, 2016 at 12:27:24AM +0200, Xen wrote:
>> Michael Biebl schreef op 11-04-16 00:22:
>>> So why don't you implement such a scheme? Talk is cheap
>>
>> Criticising an idea by saying "do it yourself" is even cheaper.
>>
>> MUCH MUCH cheaper.
>>
>> Idiot.
> 
> No he isn't.  The developers here put a lot of thought and energy
> working with numerous hardware requirements an user cases in order to
> come up with the current situation.  It works for almost everyone, which
> is vastly better than the previous scheme of "first driver loaded
> wins!", which barely worked for anyone, and caused so many problems it
> wasn't funny (just ask any of us who have been in support for a distro
> about the problems...)

I am sorry, I had wanted to explain. It is really no ones business why
you are not doing a certain thing.

For all you know someone is not capable of programming. For all you know
someone is not versed in C, or does not have the health to do such a thing.

If you are really that unimaginative to consider that there might
actually be good reasons why someone does not do a certain thing, you
are an idiot.

People like cheap labour.

I will keep it at that for now.


> If you have an alternative proposal, great, it can be fit into the
> existing system (note the heirachy of names that are picked depending on
> just how well your hardware describes itself.)  Please propose that.

I just did.

I proposed transforming the tree-like biosdev names into a linear
display, the way you can traverse a tree and produce a list.

If the biosdev names are a model of the networking hardware, that does
not imply it has to be the presentation.

You can transform the biosdev names (that are now stable, or unique)
into a presentation that agrees with the "old" names:

ethernet0
ethernet1
loopback
wireless0

bridge0

Whatever. Most systems do not have more than 1 or 2 networking devices.
If you have 2 physical nics, you probably won't also have wireless. If
you have wireless + ethernet, you might not have a 2nd wired ethernet.

You can traverse the biosdev tree and produce a list.

That was my proposal.


> If you don't like the current scheme, that's also fine, there is a
> trivial way to "opt-out" of it.
> 
> So I don't understand your complaints, you don't like the current
> scheme, yet you don't have any proposal other than "I liked the original
> way", which you still have access to.  So really, there isn't anything
> to change here that I can see, unless you have a new naming scheme that
> can be implemented as well?

That was what my whole message was about.

However, the biosdev names are not available for mapping.

Only the MAC and PCI are (as far as I know).

The naming scheme is not really important (from the viewpoint of the
creators' requirements) -- only the stability is.

Even if you lose some information when you transform the tree to a list,
or several lists, this does not impact the stability. It might impact
the predictability -- whatever it is worth, but not the stability.

Having names such as "ethernet0" "ethernet1" gives less information, but
a user does not need that information.

If the biosdev "tree" for a system is stable, then so will be a linear
transformation of that (a traversal into a list or several lists).

However this is not trivial for a user to implement because the biosdev
names are already the result of a mapping and cannot be changed.

You can only operate on their source, which is a tad complex for an
ordinary user to do, and would throw away the work the people have done.

So why not:

enp3s0 --> ethernet0
wlXXXXXX --> wireless0
lo --> loopback
br0 --> bridge0

and so forth?

It is readable, it is user friendly, if biosdev is stable, so will this
be stable. It has all the benefits of biosdev scheme except for:
predictability.

But is this not actually MORE predictable?

- If the biosdev ordering does not change, neither will this.
- The first ethernet device will again be called ethernet0 on all systems
- The first wireless device will again be called wireless0 on all systems

- You use the work the systemd people have done as a foundation to
create the stability, but you do away with the presentation of it as
something the user needs to see.

So I say simply TRANSFORM THE TREE.

Turn it into lists. What do you lose?

It will just not be "predictable" when you remove or add hardware,
because that reorders the resulting lists.

Ie, if you have:

ethernet0
ethernet1
ethernet2

And you add a new device, it might become:

ethernet0
ethernet1
ethernet2  <-- new device
ethernet3

But is that really an issue?

You can put usb devices at the end of the list.

Regards, Bart.