Re: [systemd-devel] Network Interface Names: solution for a desktop OS
On Wed, Apr 13, 2016 at 02:42:29AM +0200, Xen wrote: > When you say that probing on the PCI bus never ends, and if we are > talking not about some form of hotplugging, then I really wonder what > you're on about ;-) because I do think the kernel has a limited set of > probes that it can perform, and at some point it is going to quit. Not if it is interrupt driven, the kernel only responds to devices when they show up, it doesn't know how many devices are going to be ever found. > It seems clear that some things are only going to be done once. "once"? > So I am not sure what you are alluding to. If there is some theoretical > tail (and it has not to do with hotplugging) I'm not sure if it is ever > going to be relevant here. If there is a theoretical tail, the system > cannot wait for it anyway. The issue is that you need to create a system that allows devices to show up whenever they decide to show up, you can't "wait around" for anything as you never know just how long, or what will, or will not, show up. You have to design a system that is event driven, as that is how hardware works, and is the only way your system can work properly due to it possibly changing all the time (devices added / removed between boots, etc.) good luck! greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
13.04.2016 02:24, Jordan Hargrave пишет: > > 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. Yes. And I do not see how all this information is expected to be stuffed into 14 characters available for interface name, or even less if we account to VLAN numbers. I am not aware of any OS that tries to do it. All of them maintain persistent association between interface names and hardware characteristics; most use physical topology, but this is not really mandatory. Interface names themselves are usually allocated on the first come first serve basis. This gives reasonable behavior for small systems (where existing interface will always get the same name irrespectively of how it is connected) and stable names for large systems. That is what we used in the past as well in form of udev rules. And any answer "but you can easily disable predictable names" is hypocritical because the whole infrastructure to maintain such name database was ripped out, so anyone who disables predictable names is forced to reinvent the wheel and reimplement it. Which by far exceeds what average user is capable of. So average user simply has no choice. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Configuring ethernet link fails with No such device
[added Tom Gundersen as he seemed to have worked on udev's net link built-in] On 2016-04-12 08:44, David Miller wrote: > From: Bob Ham> Date: Tue, 12 Apr 2016 09:58:12 +0100 > >> On Mon, 2016-04-11 at 15:46 -0700, Stefan Agner wrote: >> >>> Or in other words: Is this a Kernel or systemd issue? >> >> From what I recall, both; an issue with the FEC driver, and issues in >> systemd/udevd's handling of link-level settings. > > This is my impression of the situation as well. The execution order looks as follows for the FEC driver (taken from a recent kernel with some additional printks, serial console): ... [1.157086] fec_probe ... [1.190350] fec_enet_mii_init [1.205446] libphy: fec_enet_mii_bus: probed [1.217849] fec 400d1000.ethernet eth0: registered PHC device 0 ... [ 10.751060] dev_ethtool, rc -19 => (ETHTOOL_GSET) Too early... [ 11.262333] fec_enet_open [ 11.479928] fec_enet_mii_probe => Or/and too late... Looking at the journal: ... Apr 13 01:02:49 colibri-vf systemd[1]: Started udev Coldplug all Devices. ... Apr 13 01:02:50 colibri-vf kernel: mdev_ethtool, rc -19 ... Apr 13 01:02:50 colibri-vf systemd-udevd[197]: Could not set speed or duplex of eth0 to 0 Mbps (half): No such device ... Apr 13 01:02:51 colibri-vf kernel: fec_enet_open ... Apr 13 01:02:51 colibri-vf kernel: fec_enet_mii_probe The service "udev Coldplug all Devices" essentially executes: udevadm trigger --type=subsystems --action=add ; udevadm trigger --type=devices --action=add I guess the "add" udev event is generated due to the fact that the device has successfully been probed. If the kernel is allowed to initialize the PHY as late as at open time, systemd should configure the link at a point after link up... Do you agree on that? Afact there is no udev event on link up, hence this would not be a mere udev rule change...? So I think the issue is either a systemd/udev issue or a FEC driver issue. And the solution is one of this two options: - Move (all the) PHY probes at driver probe time, then the PHY will be probed when udev processes the add event - Or move systemd/networkd/udev link processing, set the link settings only after the device has been opened (link up). Florian brought up a good point in another answer: > Part of the reason for doing that, is that probing for the PHY during > the driver's probe function could leave you with unused HW that is > powered on for no good reason. Until we get into ndo_open, we have no > clue if the interface is going to be used or not, so it is better to > move part of the HW initialization as late as possible in the process. Therefor I think only option 2 is actually viable. -- Stefan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Reindl Harald schreef op 13-04-16 02:06: > > > Am 13.04.2016 um 01:20 schrieb Xen: >> Greg KH schreef op 13-04-16 01:16: >>> On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote: All you need to do is wait a few seconds before you start renaming >>> >>> Most machines boot to login faster than a "few seconds", so: >> >> Most machines boot to login faster than a few seconds? >> >> What machines are you talking about? >> >> Anyway the 3 seconds I mentioned is or would be a relative number > > STOP IT NOW What are you on about? Just because I don't have a superfast system, I cannot say anything? If you have a system that has logged on to the internet and cracked the white house in a fraction of a millisecond, that still doesn't change or take away from anything I have said. The system still needs to do things in a certain order. That order is relevant, not actual times I just mentioned as an example. And very wonderful for you to have systems that boot in 4 seconds and you then keep running for 20 weeks. My applauds. You have saved an amazing amount of time, now you can go on a holiday. Because your system boots fast. Congratulations. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Reindl Harald schreef op 13-04-16 02:04: > > > Am 13.04.2016 um 00:03 schrieb Xen: >> 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 > > oh my god - they are oth *not* supposed to give back eth0 adn you should > at leats not throwing with words around you which have a specific > meaning in the topic Apparently it was due to systemd already doing its thing. If I turn it off, now biosdevname -i eth0 will return: p10p1 The all_ethN policy simply returns: eth0 --- this is apparently a reordered system, but since I have only one NIC, you won't see anything special. I guess this is the system that was said to create race conditions. I don't know why biosdevname is not actually used, even though the online document says so, by the systemd scheme. "The all_ethN policy makes a best guess at what the device order should be, with embedded devices first, PCI cards in ascending slot order, and ports in ascending PCI bus/device/function order breadth-first. However, this policy does not work if your PCI devices are hot-plugged or hot-plug‐gable, including the virtual functions on an SR-IOV device. In a hot-plug scenario, each separate udev instance will be invoked in parallel, while the device tree is still being populated with new devices. Each udev instance will see a different PCI tree, and thus cannot provide con‐sistent enumeration. Use of this policy should be limited to only scenarios where all PCI devices are present at boot (cold-plug)." Seems close to what I wanted. Seems almost exactly what I wanted. The "ethernet0" scheme I proposed is also only meant for cold-plug. So basically, Reindl / Greg, the thing you are criticising is already implemented and functioning in biosdevname, the program. So I don't know what you are on about. You say it cannot be done, and it has already been done. Apparently you can use it in udev rules you design yourself (I have no knowhow about that). biosdevname, according to the web page, has formed the basis for the current systemd scheme. But it is also still a program you can use to accomplish the thing I want, albeit in a limited fashion. I guess it needed a kernel parameter to be activated. You are bitching about terminology I use, but everyone already knew what I was talking about. Reminds me of this image ;-). https://s-media-cache-ak0.pinimg.com/736x/09/6a/f8/096af8445c29b9be6c485abecfac7e04.jpg As well, even though technically the biosdevname and the systemd scheme are distinct, no one of you or anyone has ever mentioned biosdevname, all of it has been about the systemd scheme and everyone understood what I was saying. So, yes, arguably pretentious. And maybe also purely pedantic here. > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html I had already seen both pages, thank you very much. It did take a while for me to sink in what biosdevname actually was, and indeed I did not differentiate, but it was also not necessary before because no one actually refered to the actual "biosdevname". So thank you for pointing it out, but if it had been relevant, someone would already have mentioned it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Greg KH schreef op 13-04-16 01:29: > On Wed, Apr 13, 2016 at 01:20:05AM +0200, Xen wrote: > All execpt for 4-socket and larger servers. They take tens of minutes > in the BIOS and then less than a minute in the kernel/userspace, > depending on the amount of memory. > > Doesn't your laptop/desktop boot that fast? If not, you are using the > wrong distro :) I have no SSD. Even a 4-rotating-disk raid-10 system using a relatively new processor (FX 6300) does definitely not boot within a few seconds. The system I'm on now has a 2.5" 5400 hdd and a mobo/cpu from 2009. Or 2010. I think it takes about 30 seconds before the network is up (by DHCP probably, is what it means). That's 30 seconds into booting the kernel, not counting the BIOS. It seems to take 22 seconds before it loads the nVidia kernel and mounts /boot and activates swap. >> Anyway the 3 seconds I mentioned is or would be a relative number. > > You have to define this in a way that will properly work. I think using timing might not be smart anyway. I don't know. >> I am sure you can provision that in your boot sequence. > > How? I would think in the initrd, the most obvious way would be to perform it right before starting networking. I'm not intimiate on current details of how booting works. In general you'd think that if networking is a target, then it would depend on the activation of the renaming/aliasing. Since the renaming has no impact on anything other than networking, you can do it right before you start that up. >> What buses are you mentioning here? > > PCI, USB, etc. There is a concept in statistics where some (or many) distributions have a "tail" that is never quite going to disappear. Even if the probability that something is going to appear in that tail might at some point be less that 0.1%, it is never going to be zero, although it converges on zero. When you say that probing on the PCI bus never ends, and if we are talking not about some form of hotplugging, then I really wonder what you're on about ;-) because I do think the kernel has a limited set of probes that it can perform, and at some point it is going to quit. It seems clear that some things are only going to be done once. So I am not sure what you are alluding to. If there is some theoretical tail (and it has not to do with hotplugging) I'm not sure if it is ever going to be relevant here. If there is a theoretical tail, the system cannot wait for it anyway. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
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
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
> On Tue, Apr 12, 2016 at 5:06 PM, Reindl Haraldwrote: Is there a ML anywhere on which you don't sputter, fume, rant and insult? If you don't like what you're reading -- walk away and don't participate. Adding yet another rule to the 'Raindl-Filter(tm)'. The filterset's getting to be almost as large as the kernel ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Am 13.04.2016 um 01:20 schrieb Xen: Greg KH schreef op 13-04-16 01:16: On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote: All you need to do is wait a few seconds before you start renaming Most machines boot to login faster than a "few seconds", so: Most machines boot to login faster than a few seconds? What machines are you talking about? Anyway the 3 seconds I mentioned is or would be a relative number STOP IT NOW Startup finished in 550ms (kernel) + 652ms (initrd) + 3.872s (userspace) = 5.074s Startup finished in 566ms (kernel) + 319ms (initrd) + 1.430s (userspace) = 2.316s Startup finished in 491ms (kernel) + 635ms (initrd) + 1.909s (userspace) = 3.036s Startup finished in 508ms (kernel) + 600ms (initrd) + 3.001s (userspace) = 4.110s Startup finished in 361ms (kernel) + 604ms (initrd) + 11.529s (userspace) = 12.495s Startup finished in 366ms (kernel) + 614ms (initrd) + 2.194s (userspace) = 3.174s Startup finished in 1.041s (kernel) + 1.120s (initrd) + 3.231s (userspace) = 5.394s Startup finished in 499ms (kernel) + 648ms (initrd) + 4.224s (userspace) = 5.372s Startup finished in 570ms (kernel) + 983ms (initrd) + 4.155s (userspace) = 5.708s Startup finished in 355ms (kernel) + 694ms (initrd) + 2.052s (userspace) = 3.102s Startup finished in 563ms (kernel) + 1.071s (initrd) + 3.103s (userspace) = 4.739s Startup finished in 1.038s (kernel) + 1.283s (initrd) + 3.385s (userspace) = 5.708s Startup finished in 585ms (kernel) + 1.368s (initrd) + 3.701s (userspace) = 5.656s Startup finished in 1.003s (kernel) + 1.269s (initrd) + 3.505s (userspace) = 5.778s Startup finished in 1.084s (kernel) + 1.163s (initrd) + 2.968s (userspace) = 5.217s Startup finished in 1.161s (kernel) + 1.200s (initrd) + 3.858s (userspace) = 6.220s Startup finished in 896ms (kernel) + 1.319s (initrd) + 3.572s (userspace) = 5.788s Startup finished in 1.071s (kernel) + 940ms (initrd) + 3.711s (userspace) = 5.723s Startup finished in 849ms (kernel) + 1.172s (initrd) + 3.130s (userspace) = 5.152s Startup finished in 982ms (kernel) + 1.176s (initrd) + 3.768s (userspace) = 5.926s Startup finished in 889ms (kernel) + 1.255s (initrd) + 3.798s (userspace) = 5.943s Startup finished in 429ms (kernel) + 1.166s (initrd) + 28.956s (userspace) = 30.552s signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Am 13.04.2016 um 00:03 schrieb Xen: 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 oh my god - they are oth *not* supposed to give back eth0 adn you should at leats not throwing with words around you which have a specific meaning in the topic https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Consistent_Network_Device_Naming_Using_biosdevname.html signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
On Wed, Apr 13, 2016 at 01:20:05AM +0200, Xen wrote: > Greg KH schreef op 13-04-16 01:16: > > On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote: > >> All you need to do is wait a few seconds before you start renaming > > > > Most machines boot to login faster than a "few seconds", so: > > Most machines boot to login faster than a few seconds? > > What machines are you talking about? All execpt for 4-socket and larger servers. They take tens of minutes in the BIOS and then less than a minute in the kernel/userspace, depending on the amount of memory. Doesn't your laptop/desktop boot that fast? If not, you are using the wrong distro :) > Anyway the 3 seconds I mentioned is or would be a relative number. You have to define this in a way that will properly work. > I am sure you can provision that in your boot sequence. How? > >> or wait on some defined trigger. > > > > Exactly what type of "defined trigger" would work for busses that you > > never know when they are finished being probed? > > What buses are you mentioning here? PCI, USB, etc. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
On Tue, Apr 12, 2016 at 5:39 PM, Xenwrote: > Just want to summarize here very shortly. > > > If you turn the hotplug naming scheme into something more attractive. > > If you turn the USB naming scheme into something more attractive. > > If you accept like a 99.9% confidence interval for waiting until > hardware has shown itself, then taking the (embedded + pci bus) numbers > and condensing that into a sequential list for ethernet and wireless > > And if you deal with any other naming scheme there might be. > > Then it would solve the utmost total majority of instability issues in > the kernel loading the driver for multiple NICs in quick succession > (this whole issue was mostly about very short intervals I believe) even > if you don't have a 100.0% guarantee (but you would have a rounded > 100% guarantee) particularly if you take into account that > networking+firewall+routing should perhaps not start for a production > system that is very important if not all networking devices for it are > present. > > If you are going to start routing and firewalling on non-present > networking devices, you have a problem anyway and the current > "PredictableNetworkInterfaceNames" is not going to solve that. > > Then you will have ethernet0 and wireless0 names for the majority (vast > majority) of consumer devices out there. > > You will have an almost 100.000% guarantee that an ordinary user with 2 > ethernet NICs (like a motherboard with 2 ports) will never ever > experience NIC swapping (eth0 becoming eth1 and vice versa). > > You will not see a difference for USB and hotplug because you only > prettify the names, compared to the current system. > > The statistical likelihood of this ever going wrong for those 2 NICs is > just very very very very small. I don't care what you say about NICs > showing up 2 hours after the system is booted. If you have a system that > has to wait 2 hours for a relevant or essential NIC, it is going to be > nonfunctional anyway. > > If you feel I'm being thick, please say so. I feel I am (but do explain > ;-)). > > I just don't see how this is going to turn into any problem ever for > anyone. If you do the renaming prior to starting networking, it is > nearly impossible EVER that this will impact real people in a real way. > > Maybe that is not acceptable. From my point of view currently with the > knowledge I have, it would work out fine and "waiting for devices to be > present before you act on it" seems like a very nice thing to do anyway. > It feels nice to me. > > It is only relevant for networking setups and if both devices you need > are not present (or even more) you should not act on it anyway and the > system should fail. Or you should have a provision that you are alerted > of networking hardware not having come online. > > There is not really any scenario where this condensing of enp3s0 names > is going to cause a problem. > > And if it does, reboot you know ;-). But it is not going to happen. > Consumer systems usually have one NIC (eth). Routers running systemd > need to guarantee that both needed devices (or more) are present before > starting networking. I bet it is not a problem for them to depend on > fixed bus names, especially if they are embedded systems. But hardware > failure would usually disrupt functioning anyway. > > And you could turn that system off if you wanted. It doesn't have to be > the same for everyone, as long as it is convenient and usable for the > majority. Right? > > All you need to do is wait a few seconds before you start renaming or > wait on some defined trigger. > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel 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
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Greg KH schreef op 13-04-16 01:16: > On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote: >> All you need to do is wait a few seconds before you start renaming > > Most machines boot to login faster than a "few seconds", so: Most machines boot to login faster than a few seconds? What machines are you talking about? Anyway the 3 seconds I mentioned is or would be a relative number. I am sure you can provision that in your boot sequence. >> or wait on some defined trigger. > > Exactly what type of "defined trigger" would work for busses that you > never know when they are finished being probed? What buses are you mentioning here? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
On Wed, Apr 13, 2016 at 12:39:37AM +0200, Xen wrote: > All you need to do is wait a few seconds before you start renaming Most machines boot to login faster than a "few seconds", so: > or wait on some defined trigger. Exactly what type of "defined trigger" would work for busses that you never know when they are finished being probed? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Just want to summarize here very shortly. If you turn the hotplug naming scheme into something more attractive. If you turn the USB naming scheme into something more attractive. If you accept like a 99.9% confidence interval for waiting until hardware has shown itself, then taking the (embedded + pci bus) numbers and condensing that into a sequential list for ethernet and wireless And if you deal with any other naming scheme there might be. Then it would solve the utmost total majority of instability issues in the kernel loading the driver for multiple NICs in quick succession (this whole issue was mostly about very short intervals I believe) even if you don't have a 100.0% guarantee (but you would have a rounded 100% guarantee) particularly if you take into account that networking+firewall+routing should perhaps not start for a production system that is very important if not all networking devices for it are present. If you are going to start routing and firewalling on non-present networking devices, you have a problem anyway and the current "PredictableNetworkInterfaceNames" is not going to solve that. Then you will have ethernet0 and wireless0 names for the majority (vast majority) of consumer devices out there. You will have an almost 100.000% guarantee that an ordinary user with 2 ethernet NICs (like a motherboard with 2 ports) will never ever experience NIC swapping (eth0 becoming eth1 and vice versa). You will not see a difference for USB and hotplug because you only prettify the names, compared to the current system. The statistical likelihood of this ever going wrong for those 2 NICs is just very very very very small. I don't care what you say about NICs showing up 2 hours after the system is booted. If you have a system that has to wait 2 hours for a relevant or essential NIC, it is going to be nonfunctional anyway. If you feel I'm being thick, please say so. I feel I am (but do explain ;-)). I just don't see how this is going to turn into any problem ever for anyone. If you do the renaming prior to starting networking, it is nearly impossible EVER that this will impact real people in a real way. Maybe that is not acceptable. From my point of view currently with the knowledge I have, it would work out fine and "waiting for devices to be present before you act on it" seems like a very nice thing to do anyway. It feels nice to me. It is only relevant for networking setups and if both devices you need are not present (or even more) you should not act on it anyway and the system should fail. Or you should have a provision that you are alerted of networking hardware not having come online. There is not really any scenario where this condensing of enp3s0 names is going to cause a problem. And if it does, reboot you know ;-). But it is not going to happen. Consumer systems usually have one NIC (eth). Routers running systemd need to guarantee that both needed devices (or more) are present before starting networking. I bet it is not a problem for them to depend on fixed bus names, especially if they are embedded systems. But hardware failure would usually disrupt functioning anyway. And you could turn that system off if you wanted. It doesn't have to be the same for everyone, as long as it is convenient and usable for the majority. Right? All you need to do is wait a few seconds before you start renaming or wait on some defined trigger. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
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 - wireless do the same: wirelessX and wifi-hotplug - wired usb: eth-usb- 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 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.99% 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
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Reindl Harald schreef op 12-04-16 20:54: >> Then do it yourself. > > what? Design or propose something better. Maybe you thought the original system was better, I guess you mentioned something like that. > i am just a user like you but with technical understanding, the point is > that you talk about things which you don't gasp in a way like you are > the king I don't see anybody else taking up the ball. And the king wouldn't do this himself, he would assign someone to do it for him. My mind is not utterly perfect and I often cannot describe myself very well. Maybe you think I am eloquent, currently, I am not. I just do my best in what you could describe as some kind of uphill battle, right. Let me just say this, and I think you can agree: Many times in life we are shoved off by people who have a superior technical understanding, which means we cannot stand up to them. But we still feel that the decisions they make are bullshit. This can be as simple as a monitor that makes noise when in standby (coilwhine or something similar) and the salesman says "that's what all devices do, that's just a part of it". We feel that an injustice is being done to us, but we don't have all the knowledge to prove it. People with more knowledge can throw us in the woods, and hide information from us what would serve us. Because they have an agenda and do not want to accept your objections or demands. Yes what I am doing is simply making a demand of some kind, and I guess you know that. I mean you are not unsympathetic to it, but I just cannot do anything well these days (my mind is too much fucked up) and this is not just here. The way these things go is that you would invite the technically knowledgeable people to prove that the decisions they've made are sound. Like Andrei Borzenkov said "You need to explain why your new naming scheme is better than that." And this is reasonably accurate you know. It doesn't work here because the person making a complaint does have to justify it. But after a complaint has been justified the people responsible for the system can also be invited to demonstrate why their system is really necessary. However this is not really happening here. So suddenly I am the one that needs to have all the knowledge. You know what it's like being governed by a technocracy. Most economical decisions in government are also made by politians who convince the populance of the necessity of their choices but meanwhile they do not reveal who is really pulling their strings and what interests they are really serving. It's the same here: the designers and important people in this industry work for some large corporations or work for vendors that supply to them. I think you will agree that what we see in this point in time is a weighing of interests and the large businesses win out. Right. And no matter my lack of technical knowhow: I can see this happening. >> Thunderbolt is a largely irrelevant technology from what it seems. > > says who? You ask why it is relevant to this topic. I was just explaining why I don't have this knowledge. As a random computer user, it is impossible that I would have in-depth knowledge about e.g. Thunderbolt or the way it is presented on the (PCI) bus. I explain why this technology is so far removed from me that I cannot possibly have either an interest, or a way to know all about it. So I hope I can be excused I do not know everything before saying something. >> Recent years have seen a proliferation of new technologies but most >> people don't even use them: >> >> * DisplayPort, the vast majority of computer users may not ever have >> used it. > > tell that the 6 workstations i am responsible for I am saying this to illustrate that the current concerns may not be concerns of the vast majority of users. The 6 workstations you are responsible for may not represent the majority, and you know that. People often talk about the disconnect between politicians and ordinary people. Well, what we see today. Do you not think it can be described as a disconnect between designers and actual users? So I will tell your 6 workstations that the vast majority of computer users may not ever have used DisplayPort. Your workstations will say, "Well, but we are bit higher end machines. Many people at home buy cheaper monitors that do not have DisplayPort. We may reflect the minority on a global scale. It's not that our technology is not widely used, but in the lower range and on smaller size monitors, it is true that a displayport connector is often not found. It is also true that displayport (I think) is mainly used for the higher resolutions it supports, which may not be relevant for smaller screens. DisplayPort is currently present on many motherboards and even laptops, but I suspect there is indeed a large share of users who have never come into contact with it. For instance, as an illustration" MSI produced an nVidia GTX 960 card with 3x DisplayPort. They
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
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 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Manuel Amador (Rudd-O) schreef op 12-04-16 12:46: > On 04/12/2016 02:26 AM, Xen wrote: >> That is completely nonsensical because it would imply that some network >> device could be initialized 2 hours after the system had booted. > > Greg KH is completely correct -- that can totally happen. If that happens you have worse problems than a renumber of network device, I'm sure you'd agree. In any case if you have a solution of hotpluggable devices, and these devices can appear anywhere in that biosdev tree, then yes mapping it to a linear set of lists might be problematic. You would need to separate hotplug vs non-hotplug. But thus far, I have demonstrated to myself that removing a non-hotplug device defeats the biosdev scheme. I cannot know at this point whether worse stuff does not happen to biosdev if you remove e.g. Thunderbolt ethernet devices. So I am not really in the position to decide or even say much about that. Use some common sense. Most of the rebuttals I get here are stuff you, yourself, are capable of solving. > But it's clear that rational, calm, evidence-based arguments aren't > swaying you. If hotplugging a device can change PCI numbers, then there is nothing rational about it. You have defeated yourself already. The PCI device is supposed to be geographical location but it changes depending on number of devices present (at least on my system). That means on my system the biosdev system behaves as the thing that I have proposed, with the exception and difference that although PCI numbers would change (do change), the resulting ethernetX networking list, would not. So for MY system my solution would work whereas your current (??) system doesn't. If you consider that irrational arguments, then I consider you a turd person. I could go and test on on the other 2 systems currently present in my house, one would require booting a live DVD, the other would require turning on diosdev in a Debian 8 system. Both are rather current. The scheme I did propose would solve the kernel reordering problem. You say or imply that some network device present-at-boot can take 2 hours to be recognised by the kernel. In that case you have worse problems than a reordering of numbers. What are you really solving here. The arbitariness in detection would be solved by my scheme by assuming that the normal period of detecting the hardware happens before the hardware is getting used. But yes, the thing I proposed is unstable if devices can get removed and those devices end up in a list you depend on. Just like when I remove a card from my computer. Because if those removable devices end up in the PCI list and are used in the enpXsY notation, you have the same problem in biosdev. So you have two situations: * If things can change order because of hotplugging, don't use a condensed iteration scheme like I proposed * (Don't use a condensed numbering scheme anyway for things that can appear/disappear due to user intervention) Maybe you think all devices fit into the category of things that can appear/disappear. However currently for me, biosdev renumbers these, while my scheme wouldn't. The second situation is: * Things that cannot change (biosdev) order would benefit from a scheme that just condenses them. Are you saying that in our current day life, everything is now up in the water? Thunderbolt can randomly change PCI numbers on the fly. A hardware (onboard) networking device can suddenly pop out of nowhere 2 hours down the road reordering a (live) system. Of course all of that can be solved with a little engineering, it depends on what you want. Does make the solution more complex. I'm not sure all of you are telling me the truth though. > So I'll try asking a question instead: > > 1. Why don't you follow the documented procedure to disable the feature > you hate? What's it with posting on the list repeatedly about it? Are you stupid? > 2. The new netdev naming system has made the lives of many people much > better (me included). Why should /your/ preference -- which would > instantly make us all worse off -- become the new default, over our > well-served needs? Counter question: why do you think your needs are well served, but anothers aren't? Who are these many people? Who do you think you represent? Who are you working for? And in case you didn't notice I tried to come up with something that wouldn't ruin the boot-after-boot stability (and I think I have) although I didn't know that "hotplugging" is really the crux of the issue here. So why don't you explain how it has made your life better and what scenario you have, instead? What kind of life do you have, that you couldn't solve with fixed MAC addresses, (for instance) that got so much better now? What corner case individual are you? Why don't you explain where you are coming from before you make such allegations. You do not creatively evaluate, but only assault. Perhaps you yourself can come up with something that would
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Am 12.04.2016 um 20:37 schrieb Xen: Reindl Harald schreef op 12-04-16 11:24: Regular hardware should not suddenly appear out of nowhere, but I do not know about that Thunderbolt thing you mentioned that is nonsense * USB hardware is often *onboard* like SD-card slots on ProLiant machines down to the HP microserver * touchpad is typically a internal USB device * hotplug exists for SATA, SAS and many other interfaces "that Thunderbolt thing you mentioned"? please do your homework https://en.wikipedia.org/wiki/Thunderbolt_%28interface%29 not that i am a big fan of the "predictable" names but you appear talking about things you have not much clue Then do it yourself. what? If you know more about it. Someone has to take up the ball, right? i did my homework Why should some average user like me know everything about a system they are designing just to say a few things on the topic of how utterly insane the current solution is? maybe you did not realize it: i am just a user like you but with technical understanding, the point is that you talk about things which you don't gasp in a way like you are the king Thunderbolt is a largely irrelevant technology from what it seems. says who? Recent years have seen a proliferation of new technologies but most people don't even use them: * DisplayPort, the vast majority of computer users may not ever have used it. tell that the 6 workstations i am responsible for * USB 3.0, I have two cases that have a front USB 3.0 port, while having motherboards that do not support them (I'm using eSATA, it is enough for me) - and another motherboard with 3.0 at the back but no support for a connector (I mean onboard). it does not matter what is enough for you When I look back at my parents, they have not even used a computer. I grew up with the technology of the 80s / 90s. Now people are going crazy about 4k displays. My mother uses less than a 37" display. I actually mean 37cm. For a television, yes that small. sad enough that you have no self-expierience as i started prohramming i was 9 years old on a C64 frankly i used that thing until 1999 but what has this to do with the topic? There are people in the world that cannot afford food, but we are selling 4k displays that no one needs, and technology that goes with it to support that data that, in the end, therefore, no one needs either. but what has this to do with the topic? Huge data, sure, it can use the technology, and maybe that is your clientele. But that also makes it clear that this is not about regular users, but probably only about server parks. but what has this to do with the topic? So Thunderbolt can connect PCIe prior to booting, causing it to obtain a number on the PCI bus? See, I don't know the exact functioning of the technology from reading that Wikipedia page (and I did, thank you). If it does obtain a number on the PCI bus, it means disconnecting it might do what? Have these people been honest about what actually happens? For the most part, the more I learn the more I am astounded as to how bad this technology is. but what has this to do with the topic? Well my apologies for not being as brilliant as I could be. I have been a loser in life lately. but what has this to do with the topic? I would like to apologize to the entire human race ;-). I have let you down :p ;-). For real. In a certain sense yes You could say I have. Or myself, or you, doesn't matter. Anyway. but what has this to do with the topic? The number of Thunderbolt devices is abysmally small and it is only going to be a success relatively speaking due to USB-C, which is also the reason USB 3 is going to be more of a sane thing in the end. but what has this to do with the topic? I do not even need Full HD in my home. I still watch DVDs and many people don't have BluRay. I am happy with 720p, it is more than what I need actually for the stuff I do. but what has this to do with the topic? If there is no provision to put Thunderbolt devices behind "regular" PCIe, and there probably won't be, what is going to happen to the biosdev naming scheme if such a device is removed? Did people think about that? Do bus numbers stay the same? What then, what else? but what has this to do with the topic? Well my apologies for not having in-depth knowledge about these issues. DO YOUR HOMEWORK about topics you start to talk about like you are the king But I was led to believe biosdev led to stability and I based my arguments on that, but it is not even stable in my own system. We were talking specifically about networking here. I do not know how many hotpluggable devices there are apart from USB, I'm sorry. DO YOUR HOMEWORK about topics you start to talk about like you are the king It appears the standard provisions for "BCMA", "CCW" and a few other things including "hotplug slot index number". The USB hardware you mention is not going to appear out of nowhere. Stay focussed
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Reindl Harald schreef op 12-04-16 11:24: >> Regular hardware should not suddenly appear out of nowhere, but I do not >> know about that Thunderbolt thing you mentioned > > that is nonsense > > * USB hardware is often *onboard* like SD-card slots on ProLiant > machines down to the HP microserver > * touchpad is typically a internal USB device > * hotplug exists for SATA, SAS and many other interfaces > > "that Thunderbolt thing you mentioned"? please do your homework > https://en.wikipedia.org/wiki/Thunderbolt_%28interface%29 > > not that i am a big fan of the "predictable" names but you appear > talking about things you have not much clue Then do it yourself. If you know more about it. Someone has to take up the ball, right? Why should some average user like me know everything about a system they are designing just to say a few things on the topic of how utterly insane the current solution is? Thunderbolt is a largely irrelevant technology from what it seems. Recent years have seen a proliferation of new technologies but most people don't even use them: * DisplayPort, the vast majority of computer users may not ever have used it. * USB 3.0, I have two cases that have a front USB 3.0 port, while having motherboards that do not support them (I'm using eSATA, it is enough for me) - and another motherboard with 3.0 at the back but no support for a connector (I mean onboard). When I look back at my parents, they have not even used a computer. I grew up with the technology of the 80s / 90s. Now people are going crazy about 4k displays. My mother uses less than a 37" display. I actually mean 37cm. For a television, yes that small. There are people in the world that cannot afford food, but we are selling 4k displays that no one needs, and technology that goes with it to support that data that, in the end, therefore, no one needs either. Huge data, sure, it can use the technology, and maybe that is your clientele. But that also makes it clear that this is not about regular users, but probably only about server parks. So Thunderbolt can connect PCIe prior to booting, causing it to obtain a number on the PCI bus? See, I don't know the exact functioning of the technology from reading that Wikipedia page (and I did, thank you). If it does obtain a number on the PCI bus, it means disconnecting it might do what? Have these people been honest about what actually happens? For the most part, the more I learn the more I am astounded as to how bad this technology is. Well my apologies for not being as brilliant as I could be. I have been a loser in life lately. I would like to apologize to the entire human race ;-). I have let you down :p ;-). For real. In a certain sense yes You could say I have. Or myself, or you, doesn't matter. Anyway. The number of Thunderbolt devices is abysmally small and it is only going to be a success relatively speaking due to USB-C, which is also the reason USB 3 is going to be more of a sane thing in the end. I do not even need Full HD in my home. I still watch DVDs and many people don't have BluRay. I am happy with 720p, it is more than what I need actually for the stuff I do. If there is no provision to put Thunderbolt devices behind "regular" PCIe, and there probably won't be, what is going to happen to the biosdev naming scheme if such a device is removed? Did people think about that? Do bus numbers stay the same? What then, what else? Well my apologies for not having in-depth knowledge about these issues. But I was led to believe biosdev led to stability and I based my arguments on that, but it is not even stable in my own system. We were talking specifically about networking here. I do not know how many hotpluggable devices there are apart from USB, I'm sorry. It appears the standard provisions for "BCMA", "CCW" and a few other things including "hotplug slot index number". The USB hardware you mention is not going to appear out of nowhere. Stay focussed here. SATA and SAS are not networking technologies. Thunderbolt can sponsor ethernet in its connection (https://en.wikipedia.org/wiki/Apple_Thunderbolt_Display) -- I do not know how that works, how should I know. What happens when you plug this device in and out, even with biosdev? I don't know. The way it goes, I would not be surprised if it renumbers all your PCI numbers. In that case PCI index numbers are not a good provision, at least not if they are used in device names. How on earth should I be able to find out just like that. Again, if this was the case, you'd be better off keeping some scheme that identifies that device or that technology. Don't hold me responsible for the mess you (or other people) have created. And give our own solution if you want. Bye. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] centos-ci
On Tue, 12.04.16 14:57, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: > >Right now the CI systems we use are all based on Ubuntu, which is > >kinda weird, as most of the systemd core developers actually work for > >RH and run Fedora locally... ;-) > > I see but It's should not matter which company you work for or which > distribution upstream developers favor otherwise you end up risking bias-ing > the product on those favored downstream distribution or the (current) > employment which is one of the root cause for the existing fragmentation in > the first place. we just want to test things on both major flavours of linux distros. debian/ubuntu-style distros are nicely covered, and we'll also have redhat/fedora-style distros covered with the rhel thing now. With systemd we support quite a number of distros, and if we cover those two flavours, then we should be in a pretty good state. > And based on your response I have to ask, is someone higher up the Red hat > ladder yanking your chain and thus the project loosing it's independence in > the process or has your and other systemd's core developers view on the > matter being independent changed? Seriously, Johann? The rhel-ci people offered us to use their spare machines, that's all. And Daniel took them up on it, and is now working on getting this hooked up. You completely misunderstand how Red Hat works... In reality, I sometimes wished RH would provide us with more of infrastructure services for systemd development. In fact though, we pretty much never used any RH infrastructure. It's all github, fdo, semaphore and the Ubuntu-ci stuff run by Canonical. In fact, Canonical contributed more infrastructure to systemd development so far than RH did. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Configuring ethernet link fails with No such device
From: Bob HamDate: Tue, 12 Apr 2016 09:58:12 +0100 > On Mon, 2016-04-11 at 15:46 -0700, Stefan Agner wrote: > >> Or in other words: Is this a Kernel or systemd issue? > > From what I recall, both; an issue with the FEC driver, and issues in > systemd/udevd's handling of link-level settings. This is my impression of the situation as well. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] centos-ci
On 04/12/2016 02:43 PM, Lennart Poettering wrote: On Tue, 12.04.16 11:52, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: Anyone know that centos is not running the latest version(s) of systemd required for the upstream bug tracker so one has to ask what notification spam is this "Can one of the admins verify this patch?" Daniel is working on adding a CI infrastructure that allows us building things on a RHEL-based system for each PR. This is work in progress, and the spamming of the PRs with the mentioned line an unfortunate mistake. We have no intention to support upstream systemd on such old RHELs, but the test systems are hacked enough with never packages to allow us test things on Red-Hat-based systems. Right now the CI systems we use are all based on Ubuntu, which is kinda weird, as most of the systemd core developers actually work for RH and run Fedora locally... ;-) I see but It's should not matter which company you work for or which distribution upstream developers favor otherwise you end up risking bias-ing the product on those favored downstream distribution or the (current) employment which is one of the root cause for the existing fragmentation in the first place. And based on your response I have to ask, is someone higher up the Red hat ladder yanking your chain and thus the project loosing it's independence in the process or has your and other systemd's core developers view on the matter being independent changed? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] centos-ci
On Tue, 12.04.16 11:52, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: > Anyone know that centos is not running the latest version(s) of systemd > required for the upstream bug tracker so one has to ask what notification > spam is this > "Can one of the admins verify this patch?" Daniel is working on adding a CI infrastructure that allows us building things on a RHEL-based system for each PR. This is work in progress, and the spamming of the PRs with the mentioned line an unfortunate mistake. We have no intention to support upstream systemd on such old RHELs, but the test systems are hacked enough with never packages to allow us test things on Red-Hat-based systems. Right now the CI systems we use are all based on Ubuntu, which is kinda weird, as most of the systemd core developers actually work for RH and run Fedora locally... ;-) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Reindl Harald schreef op 12-04-16 14:02: > Am 12.04.2016 um 14:00 schrieb Xen: >> Martin Pitt schreef op 12-04-16 12:57: >>> Xen [2016-04-12 3:37 +0200]: The trick to turn it off on the website doesn't work: ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules >>> >>> It does (at least on Debian, Ubuntu, and Fedora), but you need to >>> rebuild your initrd after doing this. >> >> Alright, thanks. That isn't listed on the website. Sorry > > the right way in doubt is to boot with following kernel params which i > mentioned for sure in that thread and so don't get why "how to disable" > ist still a topic (yes, they disable both of the 'predictable' pieces) > > net.ifnames=0 biosdevname=0 You don't have to be so nasty you know. There is no right way to do anything. I prefer not to touch my kernel (boot) configuration for whatever reason I might have for that. I'm not sure what happens if I could not depend on the current "grub" installation. Or what happens if I need to boot from some other place. I prefer for the system to be stable regardless of the boot loader. For instance, you can imagine (re)booting into the current system using kexec. I know I am making an ass of myself. But that is stuff I do. Or could want to do if it actually worked for me. Dependency on a boot loader that is in itself one of the most unreliable pieces of software I have ever come across, is not really my favourite thing I must say. I'm sorry if that sounds off. I just wanted an on-disk configuration that is based on the system and not on the bootloader, and it was possible before, and I didn't realize why it was not possible now. Editing /etc/default/grub is not really, you know. On one occasion I have had a system where I could not use update-grub because it didn't work, and I maintained a custom grub.cfg. Easy enough to edit that as well, but Grub is not my piece of cake. I'm sorry if that makes me sound like some idiot loser. I try to reduce dependencies in my systems on stuff I find to be unreliable. So if I can do this using some on-disk configuration file (or even a symlink) that's better for me. Yes and I KNOW /etc/default/grub is also on-disk. Don't mince words here, I mean, a regular config file. That ideally gets used immediately, but whatever. I just want to thank Martin Pitt for not being an ass about it (that I might be myself, I don't know). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Am 12.04.2016 um 14:00 schrieb Xen: Martin Pitt schreef op 12-04-16 12:57: Xen [2016-04-12 3:37 +0200]: The trick to turn it off on the website doesn't work: ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules It does (at least on Debian, Ubuntu, and Fedora), but you need to rebuild your initrd after doing this. Alright, thanks. That isn't listed on the website. Sorry the right way in doubt is to boot with following kernel params which i mentioned for sure in that thread and so don't get why "how to disable" ist still a topic (yes, they disable both of the 'predictable' pieces) net.ifnames=0 biosdevname=0 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Martin Pitt schreef op 12-04-16 12:57: > Xen [2016-04-12 3:37 +0200]: >> The trick to turn it off on the website doesn't work: >> >> ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules > > It does (at least on Debian, Ubuntu, and Fedora), but you need to > rebuild your initrd after doing this. Alright, thanks. That isn't listed on the website. Sorry. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] centos-ci
Anyone know that centos is not running the latest version(s) of systemd required for the upstream bug tracker so one has to ask what notification spam is this "Can one of the admins verify this patch?" JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Xen [2016-04-12 3:37 +0200]: > The trick to turn it off on the website doesn't work: > > ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules It does (at least on Debian, Ubuntu, and Fedora), but you need to rebuild your initrd after doing this. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
On 04/12/2016 02:26 AM, Xen wrote: > Greg KH schreef op 12-04-16 00:14: >>> 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. Greg KH is completely correct -- that can totally happen. But it's clear that rational, calm, evidence-based arguments aren't swaying you. So I'll try asking a question instead: 1. Why don't you follow the documented procedure to disable the feature you hate? What's it with posting on the list repeatedly about it? 2. The new netdev naming system has made the lives of many people much better (me included). Why should /your/ preference -- which would instantly make us all worse off -- become the new default, over our well-served needs? -- Rudd-O http://rudd-o.com/ signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network Interface Names: solution for a desktop OS
Am 12.04.2016 um 04:26 schrieb Xen: Greg KH schreef op 12-04-16 00:14 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 is nonsense * USB hardware is often *onboard* like SD-card slots on ProLiant machines down to the HP microserver * touchpad is typically a internal USB device * hotplug exists for SATA, SAS and many other interfaces "that Thunderbolt thing you mentioned"? please do your homework https://en.wikipedia.org/wiki/Thunderbolt_%28interface%29 not that i am a big fan of the "predictable" names but you appear talking about things you have not much clue signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Configuring ethernet link fails with No such device
On Mon, 2016-04-11 at 15:46 -0700, Stefan Agner wrote: > The FEC driver (fec_main.c) does not initialize phy_dev until the > device > has been opened, and therefor the callback > fec_enet_(get|set)_settings > returns -19. I saw the same problem with the FEC driver. From what I recall, it became clear that there was a problem with the driver returning from the eth device initialisation before the PHY was initialised, which apparently is Bad and Wrong. > Or in other words: Is this a Kernel or systemd issue? From what I recall, both; an issue with the FEC driver, and issues in systemd/udevd's handling of link-level settings. -- Bob HamSoftware Engineer Open First Collabora is hiring! Please check out our latest opportunities here: http://bit.ly/Collabora-Careers ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Configuring ethernet link fails with No such device
On 2016-04-11 18:29, David Miller wrote: > From: Stefan Agner> Date: Mon, 11 Apr 2016 15:46:08 -0700 > >> What is the expectation/definition when link configuration should be >> possible? Only after the network device got opened or before? > > Only after it is open. Drivers almost always have the entire chip in > powerdown state when it is not open, so we wouldn't be able to > properly do link settings even if we wanted to when the device is > closed. I see. Afact it is a udev rule which triggers the built-in link setup code: https://github.com/systemd/systemd/blob/09541e49ebd17b41482e447dd8194942f39788c0/rules/80-net-setup-link.rules The udev rule is triggering on action add (=> probe on driver level). At least on the device I tested, it seems that there is no event on open... Any other ideas what could be used as trigger to configure the link? -- Stefan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Callback or Event Notification from journald in case of crash
On Wed, Apr 6, 2016 at 7:04 AM, P.R.Dineshwrote: > I am using systemd, journald and systemd-coredump in my system. When a > process crashes the systemd-coredump util handles the core dump and logs a > message in the journal with MESSAGE_ID=fc2e22bc6ee647b6b90729ab34a250b1 > > Now I want to add a routine which will do post crash activities, For eg., > blinking a fault led in the system. > > I think we can poll the journal for the crash message, but is there any > other optimal way to register for a callback from journal which will be > triggered whenever a message of particular MESSAGE_ID is received. > Well, you can use sd_journal_get_fd()+poll() instead of periodic checking, but other than that, there aren't any sort of callbacks yet – you'll have to filter out messages on your side. Though I wonder if systemd-journal-remote could help here? If there are multiple clients, doing the filtering in sd-journal-remote would probably be more efficient than in each client... -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel