Reindl Harald schreef op 12-04-16 21:35: > > > Am 12.04.2016 um 21:24 schrieb Xen: >> However currently for me, biosdev renumbers these, while my scheme >> wouldn't > > wow - you even don't realise that "biosdevname" and > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ > are two completly different things
I was just curious whether installing biosdevname would change things, but apparently the program doesn't return anything for -i eth0. Or, apparently my BIOS does not give information or whatever. They are not completely different things. That online document describes that biosdevname will take predence if installed. It also, once more, describes that there are different schemes for hotplug devices (this takes care of Thunderbolt). Basically the scheme has two dimensions: prefix (en, wl, ..) and the first viable "address" naming scheme it finds. Onboard, hotplug, and card devices are apparently separated as best it can. In my case my onboard NIC ends up in the 3rd scheme. Maybe you will say that if my BIOS provided adequate information, it would have become something else and the PCI renumbering wouldn't be an issue. But still everything I wrote was about naming (and sequence condensing). And yes I want my systems by default to make sense (and for everyone else as well). From a user's perspective, my remembrance is that: - my ethernet devices have always been enpXsY - my wlan device has been something short but also something long and people report long names. Why not just pioneer a representation scheme where: - ethernet (wired) onboard and card devices are called ethernetX with any onboard device taking precedence - ethernet (hotplug) devices are called eth-hotplug<slot index number> - wireless do the same: wirelessX and wifi-hotplug<slot index number> - wired usb: eth-usb<port>-<port> such as "eth-usb1-2" There can be multiple USB controllers but USB already has a scheme like that. These controllers I think are already numbered in sequence. I'm not sure if that is stable, but it is also not very important. Make it work without requiring the PCI bus number (p0s29 is not going to be very meaningful). So you might get: eth-usb1-4 or eth-usb1.4-1-2 or something of the kind even. Make it pretty. Maybe those USB numbers are unstable too? - wireless usb: same thing: wifi-usb<path> There is no need for condensing usb numbers. Just as with PCIe-hotplug, you can't really care about any persistence. You can't really care about pretty names (too much) because it is obvious that "eth0" wouldn't make much sense for it. So propose a scheme for: - ethernet0, wireless0 as condensed numbers - eth-hotplug0, wifi-hotplug1 as port numbers - eth-usb1-4-1 as usb path, same for wifi-usb1-4-1 (could also be wifi-usb1-4p12 or wifi-usb14-12 or wifi-usb1-4_1-2 or wifi-usb1-4p1p2) And fill in the rest for stuff I haven't mentioned / don't know about. The ONLY thing that is required is that you are willing to wait a few seconds before you fix the list in the case of condensed numbers. That before networking is started, you take the list of "onboard" (embedded and card slot) devices and condense that. Meaning, you wait with renaming until you can be reasonably sure that everything has made itself known. Maybe that does not theoretically solve every possible "unstableness" but I'm pretty sure it would solve 99% of issues that people had even if you cannot guarantee it. So yes I am concerned with two things: - pretty names - condensation of some default devices. wireless0 wifi-hotplug1 ethernet0 eth-usb1-4u2 these seem reasonably sensible to me. the onboard-and-pci-card thing guarantees within bounds that no new devices are going to show up "suddenly" (like with 99% certainty or more) In statistics this is called a confidence interval. I am pretty sure a 99% confidence interval for pretty much all embedded/pci-card-hardware being recognised by the kernel drivers falls within 10 seconds, and even more sure that it is probably going to fall within a second or 3 starting from boot. On my system, other systems may be faster. "Greg KH is completely correct -- that can totally happen." (with reference to some networking device taking 2 hours to respond). I am pretty sure the occurance of that will fall outside of the 99% confidence. I mean, am I being thick here? I think that for pretty much all functional systems you can with 99% confidence state that these two types of networking hardware are going to get recognised within 3 seconds if they get recognised at all. If you do the renaming and condensing after that, you're done. It will not change hotplug, it does not depend on fixed PCI bus numbers, it will not change USB, and it will not change any other thing you don't want it to. It will just give people pretty names and predictable names and 99.999999% certainty that this will always work for them and anyone. With the only possibility that it wouldn't work, being the possibility that a networking device out of temporary failure is going to be recognised after you fix the list. Which could mean after networking is started in any case. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
