Jordan Hargrave schreef op 13-04-16 01:24: > I am the primary developer of biosdevname. I've been wanting this > naming functionality built into systemd or even the OS itself. > Primarily I am interested in servers with multiple physical and > virtual NICs but getting it working on desktops would be a bonus as > well. > > The problem lies in the mapping itself. Network devices can be on a > single, dual, or even quad-port cards. Each one of these ports can be > 'virtualized' through SR-IOV or NIC partitioning, one physical card > can potentially have hundreds of virtual NICs. Other cards implement > multiple network interfaces for a single PCI bus:dev:func pair. > SMBIOS table has a mapping from slot number to PCI device, this can be > used to determine the physical slot number of a network card (and its > ports). > > So there are at least 4 variables that you must keep track of, for add-in > cards > > PCI slot # > NIC physical port # (for multi-port cards) > NIC device ID (Each physical port can implement multiple network > devices) see mlx4 driver or i. > NIC partition number (each device can then have multiple > partitions/virtual devices) See. SR-IOV or Dell NPAR (network > partitioning) > > For embedded devices (onboard), PCI slot # is replaced by instance > number. This is also available through SMBIOS.
Given this technology and virtualisation possibilities for larger systems it seems unwanted, unnecessary and improbably that you would ever want a simple "works for everyone scheme". Any complex system that actually uses all of these features might even have 100s of "nics". If you need to be able to address all of these devices by a simple name, it becomes clear you need something structured and deterministic. Anything else would probably not make sense for the usage scenario you'd start to envision. I take it, such a usage scenario could for instance this being a host system for a hypervisor that distributes all of these individual nics to its guests (for instance, I don't know). I cannot really imagine any other system where you'd need that. But again, aside. * Do you feel pure-name addressing is the way this should be done? You are basically encoding an address in a name. The software that sets up or uses this name is going to know about the scheme or it couldn't do anything with it. To this system, these names are not going to be "black boxes", their generation and usage might see code constructing them or deconstructing them to know about its elements. What you get is something like a sequence of arrays (multi-dimensional array) but instead of addressing [0][2][4] you are going to be doing name-p0p2p4 using an encoded address. At that point you wonder whether you do not want the system to enable direct addressing of the components using a filesystem path (for instance) such as not "/sys/class/net/enp3s0" but rather "/sys/class/net/en/3/0" as a manner of speaking. So my first question and consideration is: from your point of view, do these names suffice for you, or do you require more direct addressing of the components? Then the second question is: can you imagine a need for people to map any of these names or components to well-understood "aliases" such as eth0 or ethernet0? Ideally speaking, if you set up a system of ports and virtualized ports and so on, the direct path to the root device (of such) would not be very relevant to you, as long as you can access that root device directly (e.g. through an alias). As such, this /net/en/3/0 as a root "address" might not be as meaningful to you as what would come beneath it. In other words, the subtree you have "designed" for your particular system becomes more important to you than the place where that subtree is "mounted" as long as you know where. The actual physical hardware address of your "root device" is not going to be as important as being able to address it reliably in the first place. The fact that it is going to be /net/3/0 or /net/4/0 is not going to be relevant to you. Moreoever, if you want your system to be portable, you would want it to be independent in some way of these "hardcoded" hardware addresses. You might have a system image or an entire suit of configuration tools, that is already constructed towards generating this system you want. Where your root device is going to be in this particular system, is not that important. However, while setting up, you will need to know this address and use it as the "anchor". This form of anchoring could equally well be done by using an alias. So considering that I'm actually proposing (or have been thinking about) keeping this "internal subdivision" intact while making the addressing of the root device a system-independent thing, you could for instance think that: "ethernet0" does not indicate a final port an sich, it would indicate a root ethernet device. If this device had 4 ports, they would then not be "ethernet0" "ethernet1" and so on, but you would collect them using "ethernet0-1" or whatever scheme you would use. For an encoded system where user exposure is not important, "ethernet" might indeed be too long of a name. STILL I feel that aliasing the "real hardware address" to something that is meaningful to a user (or administrator) would not be an odd thing to do at all. Perhaps you may think of the current writing I have been doing here as a way to "automatically alias" the "root ethernet devices" the system finds /on each boot/ in a predictable way given a limited number of sources (embedded, cards) such that they become meaningful to a user. Meaning: the way most people start counting or numbering at 1. We count from one, but index from zero. Indexes in general are not meaningful to people, but logically the first addresses (increments) starting from a memory location are simply 0, 1, 2, etc. So we use 0, 1, 2 as a form of addressing, while we use 1, 2, 3 as a form of "naming". These numbers are names. Some people start network segment numbering at 0. I like to start at 1. 192.168.1.1 feels better to me than 192.168.0.1, because "0" is not my "first" network, "1" is. There is no need to use "0" here because it is not really an index. It is a name. There is not really going to be any amount of memory allocation or whatever that is going to change because you start at 1 and not at 0. Even if you start at 253, nothing will happen. The "enp3s0" is an address, it is not really a name. People like to give names to things. Whatever internal subdivision you might have does not usually need names. We give names to streets but not to houses. We number houses, and although they are not really indexes they do sort of work that way, and they start usually at 1 because they are still like names a little bit. TL;DR: I want to ask whether you feel there is any valid reason for me to be proposing here that an actual address-to-name aliasing takes place here. What I have been proposing is not necessarily to do away with the addresses. Certainly I have not been proposing to kill the internal subdivision you describe. What I have been proposing is to at least add an alias to the root devices that can be used in lieu of the address. If I have a single NIC, I may want it to be ethernet0. If I have a single device that has 2 ports, I may want it to automatically become not ethernet0 and 1, but ethernet0-1 and ethernet0-2. At that point the naming becomes too verbose already, actually. So you'd really be back at "eth0-1" and "eth0-2" (which is not really possible). I would really appreciate a system where you'd have some level of control over these aliases. But that /having/ aliases would not be solely dependent on the user (that may not know how to do it). And you could also imagine a situation where these aliases were available but that if someone wanted to use the direct hardware address, that would still be possible. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel