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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel