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

[Xen]

Greg KH schreef op 12-04-16 00:14:
> On Mon, Apr 11, 2016 at 11:13:25PM +0200, Xen wrote:
>>>> 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.
> 
> How you determine if a device is "onboard" or "offboard"?  Are you going
> to know when all "onboard" devices are found before you do anything
> else?  How?

I don't know, do you know? I am just a nitwit right.

The distinction I made was between USB and non-USB.

If you map the thing onto two separate lists, problem solved.

Regular hardware should not suddenly appear out of nowhere, but I do not
know about that Thunderbolt thing you mentioned.

That would imply that in the old scheme there were amazing problems just
about anywhere. I do not think this was the case.

"Solves real problems". You still have not identified "real problems"
that plagued more than 1% of the population.


>> 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?
> 
> Not true at all, drivers are loaded whenever, at pretty much random
> times, when ever the hardware is found by the kernel.  It's
> non-deterministic and you never know when it's done for some busses
> (like USB).

That is completely nonsensical because it would imply that some network
device could be initialized 2 hours after the system had booted.

Don't make me cry.

Are you just pretending ignorance just so you can make stupid statements
about stuff that has always worked? What are you really trying to do?

I have never had any system where some hardware was suddenly found 3
hours down the line.

"whenever" -- no, not whenever, when the system starts.

Stop being so ridiculous please. This whole scheme is ridiculous. The
fact that my networking scripts will fail the moment I remove an add-on
card that has nothing to do with networking is completely and utterly
and downright ridiculous.

All PCI devices are recognised before networking starts, or networking
could never reliably start. The issue that a networking system would be
started before its required device was found, does not exist in reality,
as far as I can know, and if it did exist in reality, it would be a
terribly bad situation and everyone would be crying about it everywhere.

And I hardly doubt it is going to be "very" nondeterministic, I think if
I create and save kernel logs for my system here, it is going to be the
same each and every time.

Also, on my system the ethernet device driver is loaded within 2.6 seconds:

[    2.589977] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded

Two USB devices (both usbsticks I think) within 2.7 seconds.

The renaming happens slightly after:

[    2.656676] r8169 0000:02:00.0 enp2s0: renamed from eth0

An external hub at 2.9:

[    2.889998] hub 1-4:1.0: 4 ports detected

And the last USB message occurs at 3.34 although directly after a number
of storage devices are recognised/initialized.

Of course the rationale for the whole system was randomness in device
recognition (particularly if recognition of multiple devices occurs in a
small time frame, I would guess). Nevertheless, apart from audio and
graphics messages occuring at a later time, within 4 seconds everything
that is vital to the operation of the machine is already recognised.

That means that given 'fixed' devices (present at boot) the whole
biosdev networking tree might already be available and not change anymore.

Of course if you start plugging devices that might change. So you keep
the port numbers for USB. I don't know about other technologies.

What's so hard really.


The thing that IS hard is finding out how to disable the thing without
passing kernel parameters. I had succeeded before, but the data on the
website is not correct. So I don't know how to do it.

It is just unacceptable that if you had some kind of static
configuration (of a network device) your configuration would fail and
your internet would fail because you plugged in some device.

And this is the reality today. You (the designers) made things much worse.

Now if you have some important networking setup, but you plug in a
networking card, the entire thing falls down its face. Or any other
card: the entire thing falls down its face.

Unless, I guess, if you say, the motherboard/bios is somehow perfect to
this scheme. Well, mine is not and it is a regular AMD Gigabyte
motherboard from around 2009.

We can see what would happen on my other system (recently purchased, but
might be an older motherboard).

But that might take a while before I run it.

"Solves real problems". Let me translate "Creates real inconvenience and
might create real problems depending on what you do."

I didn't even know it was that bad, jeez.

My apologies.