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

[Xen]

Greg KH schreef op 11-04-16 22:21:
> On Mon, Apr 11, 2016 at 08:49:48PM +0200, Xen wrote:
>> 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?
> 
> Yes, it is, otherwise if it wasn't, this scheme is identical to the "no
> naming scheme at all"

Apparently you just said the current scheme is identical to that as well
(for my system).

I thought the reason for this system was stability across reboots.

If the biosdev system is stable across reboots, this one will be as
well. The old system was not stable across reboots, so what you say is
not true.


>> You can put usb devices at the end of the list.
> 
> Why last?  How do you know they go last when scanning?  How do you know
> when / if they will show up?  What about 2 USB devices?  3?

To me it seems obvious that you initialize onboard devices before USB
devices, so it would not be a "how do you know" because you do it yourself.

Also, since the current scheme puts usb devices in a slightly different
format you can identify them from the name.

You are right in saying that that would cause a list that changes as it
is getting populated. But onboard/builtin devices should definitely all
be scanned before networking is initialized right?

That means that part of the list is going to be stable for networking is
used.

Last, because regular onboard devices do not suddenly evaporate after
having been initalized.

This conceptually separates the list so that usb devices cannot change
the 'hardware' devices or its list (as it is the first part that is
never going to change again during the running of the system).

That is why "last" (makes sense, no?).

So indeed if you had multiple usb devices that you keep plugging and
unplugging, indeed they would not have stable names.

The provision for USB identification depends entirely on port numbers:

"For USB devices the full chain of port numbers of hubs is composed."

That means if you pull out some device and put it in a different port,
its name will change.

Given this fact, the stability you get is minimal at best.

So now is the question, under what scenario are you going to be basing
advanced routing configuration on fixed usb port numbers???? Wouldn't
that be insane to begin with?

Now you have a certain routing setup but it only works if you use the
same usb ports and hubs for connecting it????

Is that a real scenario? No, it isn't. More common would be the scenario
to have ONE usb device that you use in whatever port.

In the current system, it constantly changes name. In my proposed
system, it would probably always have the same name. Because an usb port
number is not meaningful.

So now you have the corner case scenario where someone uses 2 usb
devices of the same kind in fixed port positions and wants to build some
kind of routing on that.

In general you would not do anything of that kind but okay. USB and
"fixed system" is not exactly in agreement with each other. But okay.

Now you have your 2nd USB device plugged in but your first isn't. Second
based on port number / path.

If both were plugged in you would have:

wireless0  <-- first device
wireless1  <-- second device

(Just assuming these are wireless dongles)

Now you only plug the second and it becomes:

wireless1  <-- second device

Now at some point you plug the first, and the name changes.

Dynamically, while having a running system.

In the current system, their names do not change because they are based
on port.

I do not know what the "old" system did. I'm sure this never happened
because people thought about it. I'm sure you can base device names on
something else if that is necessary.

You could even turn it into "wireless-usb-u1u4i6" or something similar.

People do not care about the names of usb devices. Mostly.

They accept that these names might be quite random from their point of view.

So if you must, keep basing your name on that. I mean, what's the issue.

wlp0s29u1u2 is however pretty nondescript. Why not something a tad longer.

Something that does not require knowledge of the scheme to know that "u"
designates port number. In order to divine that this is an usb device.

Nobody who plugs in USB devices is going to want it to conform to
"eth0". That is just nonsense. People don't want that. Every computer
has a built in LAN port (except for some laptops etc). We expect it to
have an easy name. Every laptop has a built-in wlan port. We expect it
to have an easy name. Anything extra -- temporary usb connections and
the like, we don't care as much.

Since these port numbers change, you cannot base any persistent routing
on usb devices anyway. Not anything that cannot be automatically
configured. The only thing that is required is stabilty across the
session, mostly. I mean, use some common sense.

> 
> It looks like you really want the old-style naming scheme, which is
> great, you have the ability to roll back to that.  Please do so.

No. You are causing pain and suffering to millions of people.

You (...) have not inquired with anyone whether they really wanted this.

So you push something and then you say "oh, but you can opt out".

So you place the burden on the user. It doesn't belong there.

It's the same with email spam marketeers. They send you unsollicited
spam, and then they say "You only have to press this link to opt out".
Courts throw these practices out the window, in business it is not legal.

It doesn't take much effort to think of a better scheme. But you don't
think along, you only try to prove that my scheme can't work. And it is
really not hard to imagine something that will work.

But now I am going to test my interface name stability. See ya.