The Simple Things in Life

[Xen]

Markus Lankeit schreef op 20-07-2016 0:01:

> Also, the whole network device naming scheme is just a fiasco...
> Before, I could have a simple template for all my systems... now every
> system requires a unique template that takes me to the HW level to
> figure out what it might be.  And this is supposed to be more
> intuitive and/or predictable than "eth0"?

I've tried to make a point of this recently on the systemd-devel list 
but one of the Ubuntu (and Debian) devs (Martin Pitt) would have none of 
it and a kernel developer tried to show me off into the woods by coming 
up with thought experiments as to why any other solution would not be 
viable.

Basically I just think they have an agenda and won't admit to it.

Many illogical decisions become logical the moment you know the truth.

There are probably some business customers that need flawless device 
recognition while requiring absolute zero configuration from the 
viewpoint of the boot process.

Any other strategy would work, including condensing the detected 
hardware list for onboard/unpluggable devices only.

They tried to tell me that a Linux system was capable of recognising a 
hardware device that was present during boot only hours after the system 
was booted - theoretically - and that because of this a stable 
"condensation" into names such as ethernet0 would not be possible.

Ie. what if after 3 hours of using the system, a network card will 
suddenly pop up? What then of your numbering? Now you have to insert 
another card in the number and your numbers won't be right anymore.

That is the ludicrous argument to my counterargument that they gave me.

Ie. I believe the network card detection works by trying all drivers and 
seeing if they can find any card they can manage, this is a pretty 
deterministic process and will probably end pretty fast for any driver 
seeing how fast the system boots these days (particularly with SSD) and 
never has a problem. If any driver cannot find any hardware, it is 
removed from the list and never tried again.

So apparently (according to kernel documents I read online) this is a 
pretty bounded thing with a guaranteed endpoint depending on whether any 
drivers do anything really weird, which I think they don't.

However lacking my real knowledge of the thing they were able to pretty 
much shove me off into the woods as indicated or at least give other 
people the impression that I didn't know what I was talking about.

I suggested a condensation of network devices (based on the current 
scheme) into a fixed list of ethernet0, ethernet1 and so on, that would 
at once be different from the old default (the kernel names) and that 
would be executed moments prior to the activation of the networking 
system and that would fix the networking instability with about as much 
grace as the current system can foster.

Meaning, I just wanted to map the current names into fixed lists (of 
devices) but only for hardware-devices-present-at-boot (unpluggables) 
and using the current "BIOS" names as the foundation for that mapping 
(in terms of order) such that the order of those devices would never 
change as long as the mapping was done after all the devices had been 
found.

Which seems not impossible, but they told me it was.

Existing mapping (renaming) to kernel device names caused race 
conditions when done on the fly. Mapping to another fixed namespace can 
never cause race conditions. And if the condensation is done prior to 
networking being started, there can never be an issue because 
conceptually networking cannot start until all required devices have 
been found.

Ie. you cannot start some firewall if one of the required devices is 
missing.

It is a complete and conceptual end-point (target, as per systemd 
jargon) that network device recognition must have completed prior to 
doing anything with those devices; that logically the former phase must 
be completed before the next can start.

So how you can start networking while accepting as some kind of basic 
reality and possibility that 3 hours down the line, a required 
networking device will suddenly surface, is beyond me.

Yet this is what Martin Pitt and others told me.

Which to me feels like "find reasons to not have to do this thing, 
quick".

"Give him the wrong directions, quick".

"Don't let anyone think his idea is actually capable of having life, 
quick".

:-/.

What else can I make of it.

Sorry for not writing all that well. Regards.