Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wed, Mar 6, 2013 at 5:28 PM, narendr...@dell.com wrote: -Original Message- From: devel-boun...@lists.fedoraproject.org [mailto:devel- boun...@lists.fedoraproject.org] On Behalf Of Michal Schmidt Sent: Tuesday, March 05, 2013 10:22 PM To: devel@lists.fedoraproject.org Subject: Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names On 03/04/2013 04:01 PM, Matt Domsch wrote: drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; I think sfc does not really *need* to set dev_id. Yes, these are multi-port cards, but the ports are on distinct PCI functions. I think setting of 'dev_id' by drivers/devices used in enterprise server environment will be beneficial, not just for devices in which multiple ports share a single PCI d/b/d/f(1 PCI d/b/d/f - 2 ports), also for multiport devices with 1 PCI d/b/d/f - 1 Port mapping. The following scenarios demonstrate the requirement/usefulness - 1. As the dev_id would indicate the physical port number used by a netdevice and will be available to user space via sysfs, tools such as NetworkManager could use the information to implement intelligent/smarter bonding of netdevices. For example, when bonding netdevices coming from NIC partitions (or SR-IOV VFs) which use the same physical port, in fault tolerance mode for example, NM could inform the user that the netdevices being enslaved map to/use the same physical port and bonding them may not have desired effect. Dev_id would provide such information in a generic way. 2. biosdevname could possibly use 'dev_id' to determine the port part of pslotpport eliminating the need to determine/enumerate port number as pointed out here. Using dev_id in the kernel for static and predictable per-device properties is fine, sure. Using dev_id with per-driver-global internal counters, or anything else that depends on any sort of probing or loading order is not; the range of dev_id must be local to every instance than can be separated and which the driver handles. Otherwise, I would not be surprised if the creativity of people would introduce new artificial and unpredictable enumerations in the kernel with that facility. :) Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Mar 5, 2013 at 5:52 PM, Michal Schmidt mschm...@redhat.com wrote: On 03/04/2013 04:01 PM, Matt Domsch wrote: drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; I think sfc does not really *need* to set dev_id. Yes, these are multi-port cards, but the ports are on distinct PCI functions. Which actually means they should leave it alone then, and not do anything. The dev_id stuff is really not to be used across different parent devices. If there is any order unpredictable probing order enumeration logic involved in the driver spanning multiple parents, using dev_id will actually break things and not help anything. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RE: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
-Original Message- From: devel-boun...@lists.fedoraproject.org [mailto:devel- boun...@lists.fedoraproject.org] On Behalf Of Michal Schmidt Sent: Tuesday, March 05, 2013 10:22 PM To: devel@lists.fedoraproject.org Subject: Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names On 03/04/2013 04:01 PM, Matt Domsch wrote: drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; I think sfc does not really *need* to set dev_id. Yes, these are multi-port cards, but the ports are on distinct PCI functions. I think setting of 'dev_id' by drivers/devices used in enterprise server environment will be beneficial, not just for devices in which multiple ports share a single PCI d/b/d/f(1 PCI d/b/d/f - 2 ports), also for multiport devices with 1 PCI d/b/d/f - 1 Port mapping. The following scenarios demonstrate the requirement/usefulness - 1. As the dev_id would indicate the physical port number used by a netdevice and will be available to user space via sysfs, tools such as NetworkManager could use the information to implement intelligent/smarter bonding of netdevices. For example, when bonding netdevices coming from NIC partitions (or SR-IOV VFs) which use the same physical port, in fault tolerance mode for example, NM could inform the user that the netdevices being enslaved map to/use the same physical port and bonding them may not have desired effect. Dev_id would provide such information in a generic way. 2. biosdevname could possibly use 'dev_id' to determine the port part of pslotpport eliminating the need to determine/enumerate port number as pointed out here. With regards, Narendra K -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 03/04/2013 04:01 PM, Matt Domsch wrote: drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; I think sfc does not really *need* to set dev_id. Yes, these are multi-port cards, but the ports are on distinct PCI functions. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Feb 25, 2013 at 11:02:55AM -0600, Andy Gospodarek wrote: On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote: Matt Domsch (matt_dom...@dell.com) said: On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote: If we can solve the installtime naming convention choice to not eliminate biosdevname, be able to disable systemd/udevd naming, and have the default be possible on a per-system-vendor basis, and solve the NPAR/SR-IOV/Mellanox naming problems, then I can support this proposal. Without fixing these shortcomings though, my customers will have a fit at me. If you're agreeing that biosdevname should be limited to type9/type41 (if I'm reading you right), and if the systemd/udev names still use those fields, what parts of biosdevname are you still requiring? The actual namespace used, or something else? I'd prefer if we didn't force users through another namespace change. I took a lot of flack for changing the namespace once. From their perspective, it's still udev doing the renaming, only now the code moved from a udev helper into udev itself. True; the users likely don't care other than how they enable/disable it. I'd like to see the SR-IOV NPAR devices handled. Those aren't represented in type9/type41, and their commonplace on Dell systems. I'd like to see the Dell-specific PCI VPD-R code from biosdevname included in udev, as that's used to map multi-port devices to port numbers. Those aren't represented in type9/type41, and they're commonplace on Dell systems. OK. I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. Do we have a list of these, or is it a matter of doing a driver audit? CC'ing gospo. (Thanks, Bill, though I've been following this thread as I am on the list). Right now almost no drivers actually set dev_id. In fact mlx4_en, cxgb4, and sfc seem to be the only ones right now. If we feel like this a requirement there will be work on the kernel side to add this. The challenge here is that because struct netdev is initialized to all zeros, code that consumes dev_id can't tell the difference between a driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a default (unset) value of 0. I think the only solution here is to make sure the kernel drivers, if they need to set it, always set this non-zero, so udev, seeing a non-zero value, knows it's a valid value to use. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Feb 28, 2013 at 09:20:51AM -0600, John Reiser wrote: On 02/28/2013 06:55 AM, Kay Sievers wrote: On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek agosp...@redhat.com wrote: I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. Do we have a list of these, or is it a matter of doing a driver audit? CC'ing gospo. Right now almost no drivers actually set dev_id. In fact mlx4_en, cxgb4, and sfc seem to be the only ones right now. If we feel like this a requirement there will be work on the kernel side to add this. This only matters if there are multiple devices created by a driver for one and the same pci device. Like when we have only one entry in lspci, but multiple interfaces of the same type having this one device as a parent. Is this really common? I would expect this is a very rare exception. How does this relate to a hosting service which assigns a different IP4 for each client domain to the same physical ethernet port? My service has many dozen different IP4 [advertised via DNS] assigned to the same port. No conceptual change here. You would still assign many IPv4 addressess to the same network device, just as you always have. The only difference is instead of assigning them to device eth0, you would assign them to device en1. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote: On Mon, Feb 25, 2013 at 11:02:55AM -0600, Andy Gospodarek wrote: On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote: Matt Domsch (matt_dom...@dell.com) said: On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote: If we can solve the installtime naming convention choice to not eliminate biosdevname, be able to disable systemd/udevd naming, and have the default be possible on a per-system-vendor basis, and solve the NPAR/SR-IOV/Mellanox naming problems, then I can support this proposal. Without fixing these shortcomings though, my customers will have a fit at me. If you're agreeing that biosdevname should be limited to type9/type41 (if I'm reading you right), and if the systemd/udev names still use those fields, what parts of biosdevname are you still requiring? The actual namespace used, or something else? I'd prefer if we didn't force users through another namespace change. I took a lot of flack for changing the namespace once. From their perspective, it's still udev doing the renaming, only now the code moved from a udev helper into udev itself. True; the users likely don't care other than how they enable/disable it. I'd like to see the SR-IOV NPAR devices handled. Those aren't represented in type9/type41, and their commonplace on Dell systems. I'd like to see the Dell-specific PCI VPD-R code from biosdevname included in udev, as that's used to map multi-port devices to port numbers. Those aren't represented in type9/type41, and they're commonplace on Dell systems. OK. I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. Do we have a list of these, or is it a matter of doing a driver audit? CC'ing gospo. (Thanks, Bill, though I've been following this thread as I am on the list). Right now almost no drivers actually set dev_id. In fact mlx4_en, cxgb4, and sfc seem to be the only ones right now. If we feel like this a requirement there will be work on the kernel side to add this. The challenge here is that because struct netdev is initialized to all zeros, code that consumes dev_id can't tell the difference between a driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a default (unset) value of 0. I think the only solution here is to make sure the kernel drivers, if they need to set it, always set this non-zero, so udev, seeing a non-zero value, knows it's a valid value to use. These seem to be the 4 drivers currently setting dev_id: drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: adap-port[i]-dev_id = j; drivers/net/ethernet/freescale/fec.c: fep-dev_id = dev_id++; drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev-dev_id = port - 1; drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; of these, both the mlx4 and siena drivers set them starting at 0. I think the fec driver might be doing so as well, but it's not as obvious. I'm pretty sure cxgb4 starts numbering at 1 just from reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be comfortable relying on the value of dev_id. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 04, 2013 at 09:01:35AM -0600, Matt Domsch wrote: On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote: On Mon, Feb 25, 2013 at 11:02:55AM -0600, Andy Gospodarek wrote: On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote: Matt Domsch (matt_dom...@dell.com) said: On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote: If we can solve the installtime naming convention choice to not eliminate biosdevname, be able to disable systemd/udevd naming, and have the default be possible on a per-system-vendor basis, and solve the NPAR/SR-IOV/Mellanox naming problems, then I can support this proposal. Without fixing these shortcomings though, my customers will have a fit at me. If you're agreeing that biosdevname should be limited to type9/type41 (if I'm reading you right), and if the systemd/udev names still use those fields, what parts of biosdevname are you still requiring? The actual namespace used, or something else? I'd prefer if we didn't force users through another namespace change. I took a lot of flack for changing the namespace once. From their perspective, it's still udev doing the renaming, only now the code moved from a udev helper into udev itself. True; the users likely don't care other than how they enable/disable it. I'd like to see the SR-IOV NPAR devices handled. Those aren't represented in type9/type41, and their commonplace on Dell systems. I'd like to see the Dell-specific PCI VPD-R code from biosdevname included in udev, as that's used to map multi-port devices to port numbers. Those aren't represented in type9/type41, and they're commonplace on Dell systems. OK. I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. Do we have a list of these, or is it a matter of doing a driver audit? CC'ing gospo. (Thanks, Bill, though I've been following this thread as I am on the list). Right now almost no drivers actually set dev_id. In fact mlx4_en, cxgb4, and sfc seem to be the only ones right now. If we feel like this a requirement there will be work on the kernel side to add this. The challenge here is that because struct netdev is initialized to all zeros, code that consumes dev_id can't tell the difference between a driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a default (unset) value of 0. I think the only solution here is to make sure the kernel drivers, if they need to set it, always set this non-zero, so udev, seeing a non-zero value, knows it's a valid value to use. These seem to be the 4 drivers currently setting dev_id: drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: adap-port[i]-dev_id = j; drivers/net/ethernet/freescale/fec.c: fep-dev_id = dev_id++; Look up a few lines: /* setup board info structure */ fep = netdev_priv(ndev); fep is not a pointer to the net_device, but to the private device structure. This is why I didn't include it in the list. drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev-dev_id = port - 1; drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; of these, both the mlx4 and siena drivers set them starting at 0. I think the fec driver might be doing so as well, but it's not as obvious. I'm pretty sure cxgb4 starts numbering at 1 just from reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be comfortable relying on the value of dev_id. I agree it looks like some cleanup is needed due to the inconsistency. This is still only an issue when a single function supports multiple ethernet devices, right? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 04, 2013 at 10:03:01AM -0600, Andy Gospodarek wrote: On Mon, Mar 04, 2013 at 09:01:35AM -0600, Matt Domsch wrote: On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote: The challenge here is that because struct netdev is initialized to all zeros, code that consumes dev_id can't tell the difference between a driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a default (unset) value of 0. I think the only solution here is to make sure the kernel drivers, if they need to set it, always set this non-zero, so udev, seeing a non-zero value, knows it's a valid value to use. These seem to be the 4 drivers currently setting dev_id: drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: adap-port[i]-dev_id = j; drivers/net/ethernet/freescale/fec.c: fep-dev_id = dev_id++; Look up a few lines: /* setup board info structure */ fep = netdev_priv(ndev); fep is not a pointer to the net_device, but to the private device structure. This is why I didn't include it in the list. Good catch. drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev-dev_id = port - 1; drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; of these, both the mlx4 and siena drivers set them starting at 0. I think the fec driver might be doing so as well, but it's not as obvious. I'm pretty sure cxgb4 starts numbering at 1 just from reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be comfortable relying on the value of dev_id. I agree it looks like some cleanup is needed due to the inconsistency. This is still only an issue when a single function supports multiple ethernet devices, right? I believe so, yes. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 04, 2013 at 10:19:14AM -0600, Matt Domsch wrote: On Mon, Mar 04, 2013 at 10:03:01AM -0600, Andy Gospodarek wrote: On Mon, Mar 04, 2013 at 09:01:35AM -0600, Matt Domsch wrote: On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote: The challenge here is that because struct netdev is initialized to all zeros, code that consumes dev_id can't tell the difference between a driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a default (unset) value of 0. I think the only solution here is to make sure the kernel drivers, if they need to set it, always set this non-zero, so udev, seeing a non-zero value, knows it's a valid value to use. These seem to be the 4 drivers currently setting dev_id: drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: adap-port[i]-dev_id = j; drivers/net/ethernet/freescale/fec.c: fep-dev_id = dev_id++; Look up a few lines: /* setup board info structure */ fep = netdev_priv(ndev); fep is not a pointer to the net_device, but to the private device structure. This is why I didn't include it in the list. Good catch. drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev-dev_id = port - 1; drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; of these, both the mlx4 and siena drivers set them starting at 0. I think the fec driver might be doing so as well, but it's not as obvious. I'm pretty sure cxgb4 starts numbering at 1 just from reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be comfortable relying on the value of dev_id. I agree it looks like some cleanup is needed due to the inconsistency. This is still only an issue when a single function supports multiple ethernet devices, right? I believe so, yes. Ok, good. I did like your idea to possibly set this to something other than 0 in the default case and then make sure that any driver that needs to set it can do so. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 4, 2013 at 6:01 PM, Andy Gospodarek agosp...@redhat.com wrote: On Mon, Mar 04, 2013 at 10:19:14AM -0600, Matt Domsch wrote: drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev-dev_id = port - 1; drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; of these, both the mlx4 and siena drivers set them starting at 0. I think the fec driver might be doing so as well, but it's not as obvious. I'm pretty sure cxgb4 starts numbering at 1 just from reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be comfortable relying on the value of dev_id. I agree it looks like some cleanup is needed due to the inconsistency. This is still only an issue when a single function supports multiple ethernet devices, right? I believe so, yes. Ok, good. I did like your idea to possibly set this to something other than 0 in the default case and then make sure that any driver that needs to set it can do so. The udev code just appends the dev_id number to the device name if dev_id is 0, so either starting at 0 or at 1 would work fine and produce reliable results. Starting at 1 would create slightly more consistent names, where all names of one and the same card follow the same scheme, and 0 is not special because it is suppressed. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Kay Sievers (k...@vrfy.org) said: On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek agosp...@redhat.com wrote: I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. Do we have a list of these, or is it a matter of doing a driver audit? CC'ing gospo. Right now almost no drivers actually set dev_id. In fact mlx4_en, cxgb4, and sfc seem to be the only ones right now. If we feel like this a requirement there will be work on the kernel side to add this. This only matters if there are multiple devices created by a driver for one and the same pci device. Like when we have only one entry in lspci, but multiple interfaces of the same type having this one device as a parent. Is this really common? I would expect this is a very rare exception. It definitely happens with some drivers, because I remember back in the ancient ancient kudzu days having to hack in a fix for this. The guilty driver in that initial case was Chelsio cxgb3, so it apparently would need fixed per above. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek agosp...@redhat.com wrote: I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. Do we have a list of these, or is it a matter of doing a driver audit? CC'ing gospo. Right now almost no drivers actually set dev_id. In fact mlx4_en, cxgb4, and sfc seem to be the only ones right now. If we feel like this a requirement there will be work on the kernel side to add this. This only matters if there are multiple devices created by a driver for one and the same pci device. Like when we have only one entry in lspci, but multiple interfaces of the same type having this one device as a parent. Is this really common? I would expect this is a very rare exception. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 02/28/2013 06:55 AM, Kay Sievers wrote: On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek agosp...@redhat.com wrote: I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. Do we have a list of these, or is it a matter of doing a driver audit? CC'ing gospo. Right now almost no drivers actually set dev_id. In fact mlx4_en, cxgb4, and sfc seem to be the only ones right now. If we feel like this a requirement there will be work on the kernel side to add this. This only matters if there are multiple devices created by a driver for one and the same pci device. Like when we have only one entry in lspci, but multiple interfaces of the same type having this one device as a parent. Is this really common? I would expect this is a very rare exception. How does this relate to a hosting service which assigns a different IP4 for each client domain to the same physical ethernet port? My service has many dozen different IP4 [advertised via DNS] assigned to the same port. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote: Matt Domsch (matt_dom...@dell.com) said: On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote: If we can solve the installtime naming convention choice to not eliminate biosdevname, be able to disable systemd/udevd naming, and have the default be possible on a per-system-vendor basis, and solve the NPAR/SR-IOV/Mellanox naming problems, then I can support this proposal. Without fixing these shortcomings though, my customers will have a fit at me. If you're agreeing that biosdevname should be limited to type9/type41 (if I'm reading you right), and if the systemd/udev names still use those fields, what parts of biosdevname are you still requiring? The actual namespace used, or something else? I'd prefer if we didn't force users through another namespace change. I took a lot of flack for changing the namespace once. From their perspective, it's still udev doing the renaming, only now the code moved from a udev helper into udev itself. True; the users likely don't care other than how they enable/disable it. I'd like to see the SR-IOV NPAR devices handled. Those aren't represented in type9/type41, and their commonplace on Dell systems. I'd like to see the Dell-specific PCI VPD-R code from biosdevname included in udev, as that's used to map multi-port devices to port numbers. Those aren't represented in type9/type41, and they're commonplace on Dell systems. OK. I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. Do we have a list of these, or is it a matter of doing a driver audit? CC'ing gospo. (Thanks, Bill, though I've been following this thread as I am on the list). Right now almost no drivers actually set dev_id. In fact mlx4_en, cxgb4, and sfc seem to be the only ones right now. If we feel like this a requirement there will be work on the kernel side to add this. So, aside from the naming convention change (which, hey, if someone else takes the pain for making that change again, not me or my company - go nuts!), the rest is straightforward technical and code can be cribbed if desired from biosdevname or just rewritten. OK, thanks. Let's see what we can do here. My concern is the conflict between trying to cover all of the cases, and trying to avoid writing documentation that is a lot of if your device is hereh, then your name is Y or Z depending on which commandline you booted with when you installed.' Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Matt Domsch (matt_dom...@dell.com) said: On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote: If we can solve the installtime naming convention choice to not eliminate biosdevname, be able to disable systemd/udevd naming, and have the default be possible on a per-system-vendor basis, and solve the NPAR/SR-IOV/Mellanox naming problems, then I can support this proposal. Without fixing these shortcomings though, my customers will have a fit at me. If you're agreeing that biosdevname should be limited to type9/type41 (if I'm reading you right), and if the systemd/udev names still use those fields, what parts of biosdevname are you still requiring? The actual namespace used, or something else? I'd prefer if we didn't force users through another namespace change. I took a lot of flack for changing the namespace once. From their perspective, it's still udev doing the renaming, only now the code moved from a udev helper into udev itself. True; the users likely don't care other than how they enable/disable it. I'd like to see the SR-IOV NPAR devices handled. Those aren't represented in type9/type41, and their commonplace on Dell systems. I'd like to see the Dell-specific PCI VPD-R code from biosdevname included in udev, as that's used to map multi-port devices to port numbers. Those aren't represented in type9/type41, and they're commonplace on Dell systems. OK. I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. Do we have a list of these, or is it a matter of doing a driver audit? CC'ing gospo. So, aside from the naming convention change (which, hey, if someone else takes the pain for making that change again, not me or my company - go nuts!), the rest is straightforward technical and code can be cribbed if desired from biosdevname or just rewritten. OK, thanks. Let's see what we can do here. My concern is the conflict between trying to cover all of the cases, and trying to avoid writing documentation that is a lot of if your device is hereh, then your name is Y or Z depending on which commandline you booted with when you installed.' Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote: If we can solve the installtime naming convention choice to not eliminate biosdevname, be able to disable systemd/udevd naming, and have the default be possible on a per-system-vendor basis, and solve the NPAR/SR-IOV/Mellanox naming problems, then I can support this proposal. Without fixing these shortcomings though, my customers will have a fit at me. If you're agreeing that biosdevname should be limited to type9/type41 (if I'm reading you right), and if the systemd/udev names still use those fields, what parts of biosdevname are you still requiring? The actual namespace used, or something else? I'd prefer if we didn't force users through another namespace change. I took a lot of flack for changing the namespace once. From their perspective, it's still udev doing the renaming, only now the code moved from a udev helper into udev itself. I'd like to see the SR-IOV NPAR devices handled. Those aren't represented in type9/type41, and their commonplace on Dell systems. I'd like to see the Dell-specific PCI VPD-R code from biosdevname included in udev, as that's used to map multi-port devices to port numbers. Those aren't represented in type9/type41, and they're commonplace on Dell systems. I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. So, aside from the naming convention change (which, hey, if someone else takes the pain for making that change again, not me or my company - go nuts!), the rest is straightforward technical and code can be cribbed if desired from biosdevname or just rewritten. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Matt Domsch (matt_dom...@dell.com) said: The RHEL model of disabling biosdevname by some hardware vendors, at installtime, is not accounted for in the current proposal. I find this model pretty broken - if we want to have clear semantics that are easily explainable to users and admins, we don't want the namespaces being used to be conditional on the hardware vendor (other than insasmuch as they have proper information in their bios.) I know how RHEL 6 did it, but that was a matter of expediency with late change. I agree, that's the right approach, which is why Dell pushed to get the SMBIOS and PCI specifications amended to put explicit per-device information into there. I hope we can work together to do likewise for cases coming up now that aren't currently addressed. If we can solve the installtime naming convention choice to not eliminate biosdevname, be able to disable systemd/udevd naming, and have the default be possible on a per-system-vendor basis, and solve the NPAR/SR-IOV/Mellanox naming problems, then I can support this proposal. Without fixing these shortcomings though, my customers will have a fit at me. If you're agreeing that biosdevname should be limited to type9/type41 (if I'm reading you right), and if the systemd/udev names still use those fields, what parts of biosdevname are you still requiring? The actual namespace used, or something else? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Feb 07, 2013 at 09:22:40PM -0600, Kay Sievers wrote:
On Thu, Feb 7, 2013 at 7:12 AM, Matt Domsch matt_dom...@dell.com wrote:
We
will need a method to enable/disable on a per-vendor basis as we
added to RHEL in the udev rules that invoke (or don't) biosdevname.
The suggestion of linking in (or not) rules files won't work for a
distro-wide per-vendor configuration.
Udev rules are installed in /usr/lib and can be masked by creating
empty files in /etc with the same file name. That way entire rules
files can be enabled/disabled, if needed.
I am concerned about the naming convention at installtime. The
current proposal removes biosdevname from comps @core as mandatory,
and I presume would also remove it from the anaconda install
environment as well. This leaves the kernel default naming scheme,
which we agree is poor. So I also presume this proposal will be
extended to enable systemd/udevd naming at installtime, which for all
network installs the device naming is prompted for on screen and/or
read from kickstart files. In this proposal there is no way to use
biosdevname names at installtime, or disable systemd/udevd names
entirely if so desired (akin to biosdevname=0 on the kernel command
line). The RHEL model of disabling biosdevname by some hardware
vendors, at installtime, is not accounted for in the current proposal.
If needed, we could add a kernel command line option to the rules too.
We do need this. We also need to be able to enable biosdevname at
installtime, again by kernel command line. The existing biosdevname=1
flag seems a good choice.
I am less concerned about runtime, as actions can be taken at runtime
to enable/disable/change the naming conventions for future boots. I
agree anything can be done at runtime given a smart system
administrator (as much as I would like not to rely on a smart system
administrator for each install).
C) There are several cases that biosdevname handles that udev doesn't
(yet) - NPAR and SR-IOV at least. These are widely used in Dell
and other vendors' servers.
These SR-IOV show up with their own PCI function number in the kernel
and they are unique that way. From my point of view this is good
enough and we don't need to do anything here. If people want pretty
names they should provide custom and meaningful names on their own.
Udev does not want to establish any cross-device relations for naming,
and only look at the single device it is currently handling.
I disagree that users should provide their own pretty names, when we
do have all the information we need about these devices to provide
pretty names by default ourselves. By the same argument, I don't
need anything more from systemd/udevd now than I've had for years with
70-persistent-net.rules files.
There are very good reasons to, in the device name, identify the
separate (to the kernel) devices that represent the same physical
cable jack. Dell's engineers have been adding code to the bonding
driver to recognize when someone is bonding two kernel devices that
share a single physical cable jack, as that's not usually the intended
configuration. With the growing set of applicance distributions
that auto-configure bonding across all visible network devices, this
is even more important.
The biosdevname convention of using _{1234} to identify such
sub-devices is mirrored in your convention of appending f{1234}.
Which works until you get to single PCI b/d/f devices with multiple
ports (e.g. Mellanox adapters), after which you need further
information to disambiguate the network devices. The biosdevname
maintainers are trying to tackle this right now.
D) the udev scheme will run out of characters in IFNAMSIZ (you've got
at most 15 chars to work with,
Sure, it's an unfortunate kernel limitation we have to live with. We
just do not rename anything if the name we composed does not fit. It's
not really a problem, more an exotic corner case that can be
covered/fixed by custom config if it really happens.
really less 5 because decimal-based
VLAN tagging is allowed, hence MAC-based won't fit).
VLANS do not need to be named with their number in the network device
name, they are created by custom config and not by detected hardware,
so the naming problem can be solved at that level too, instead of the
hardware-centric view udev has. For now, all VLANs are ignored by
udev.
VLAN devices are created in userspace by vconfig, with its own naming
policy:
* name-type: VLAN_PLUS_VID (vlan0005), VLAN_PLUS_VID_NO_PAD (vlan5),
DEV_PLUS_VID (eth0.0005), DEV_PLUS_VID_NO_PAD (eth0.5)
I agree udev doesn't need to know about them explicitly, but the
naming convention does need to account for that use of IFNAMSIZ space.
I think userspace enumeration as a general concept to start with
cannot work on today's systems. With a few exceptions, no device
naming should ever look at other devices for its own name, it's a
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Feb 12, 2013 at 4:44 PM, Matt Domsch matt_dom...@dell.com wrote:
I am concerned about the naming convention at installtime. The
current proposal removes biosdevname from comps @core as mandatory,
and I presume would also remove it from the anaconda install
environment as well. This leaves the kernel default naming scheme,
which we agree is poor.
The default scheme is always the udev names, if they are not
explicitly disabled. Everything else would be customization. We can
add whatever is needed here to help specific requirements.
These SR-IOV show up with their own PCI function number in the kernel
and they are unique that way. From my point of view this is good
enough and we don't need to do anything here. If people want pretty
names they should provide custom and meaningful names on their own.
Udev does not want to establish any cross-device relations for naming,
and only look at the single device it is currently handling.
I disagree that users should provide their own pretty names, when we
do have all the information we need about these devices to provide
pretty names by default ourselves. By the same argument, I don't
need anything more from systemd/udevd now than I've had for years with
70-persistent-net.rules files.
Well, we cannot have everything, we either have somewhat fragile
pretty names composed by several sources and properties, spanning
multiple devices, and the overall system state. Or we have the ugly
but reliable and predictable names, which are a single device only.
Udev can only do the ugly version of the names, but the deal fits
better what we do for other subsystems, and is like 100 times
simpler than what is required to do the pretty names. And reliability,
predictability, simplicity is actually what we looking for. We just
leave the pretty part to custom configuration.
There are very good reasons to, in the device name, identify the
separate (to the kernel) devices that represent the same physical
cable jack. Dell's engineers have been adding code to the bonding
driver to recognize when someone is bonding two kernel devices that
share a single physical cable jack, as that's not usually the intended
configuration. With the growing set of applicance distributions
that auto-configure bonding across all visible network devices, this
is even more important.
Sure, but custom config can add custom config for the used names too.
Having tools magically coming up with device names based on other
custom config is really nothing we ever would want to do. As soon as
custom config is in the game, there is really no need to try to be
smart, the tools that create the base config can create that config
along with it.
The biosdevname convention of using _{1234} to identify such
sub-devices is mirrored in your convention of appending f{1234}.
Which works until you get to single PCI b/d/f devices with multiple
ports (e.g. Mellanox adapters), after which you need further
information to disambiguate the network devices. The biosdevname
maintainers are trying to tackle this right now.
This really sounds like the wrong layer of fixing the issue.
If Mellanox adapters create multiple interfaces per parent device, the
kernel driver should set the dev_id of the devices, which is an
index per instance to distinguish the devices. Udev will automatically
appended the dev_id to the device name as u1,u2,... and all the names
will be unique again. We already used dev_id for the persistent net
rules in old udev revisions.
This should work all fine without any further logic, as long as the
kernel driver do the right thing here. Inventing new numbers by
checking sibling devices should be avoided here too.
Thanks,
Kay
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Feb 7, 2013 at 7:12 AM, Matt Domsch matt_dom...@dell.com wrote: We will need a method to enable/disable on a per-vendor basis as we added to RHEL in the udev rules that invoke (or don't) biosdevname. The suggestion of linking in (or not) rules files won't work for a distro-wide per-vendor configuration. Udev rules are installed in /usr/lib and can be masked by creating empty files in /etc with the same file name. That way entire rules files can be enabled/disabled, if needed. If needed, we could add a kernel command line option to the rules too. C) There are several cases that biosdevname handles that udev doesn't (yet) - NPAR and SR-IOV at least. These are widely used in Dell and other vendors' servers. These SR-IOV show up with their own PCI function number in the kernel and they are unique that way. From my point of view this is good enough and we don't need to do anything here. If people want pretty names they should provide custom and meaningful names on their own. Udev does not want to establish any cross-device relations for naming, and only look at the single device it is currently handling. D) the udev scheme will run out of characters in IFNAMSIZ (you've got at most 15 chars to work with, Sure, it's an unfortunate kernel limitation we have to live with. We just do not rename anything if the name we composed does not fit. It's not really a problem, more an exotic corner case that can be covered/fixed by custom config if it really happens. really less 5 because decimal-based VLAN tagging is allowed, hence MAC-based won't fit). VLANS do not need to be named with their number in the network device name, they are created by custom config and not by detected hardware, so the naming problem can be solved at that level too, instead of the hardware-centric view udev has. For now, all VLANs are ignored by udev. Once you allow NPAR/SR-IOV you need at least 4 characters there (e.g. i254 as suffix), leaving you with 6 usable. As mentioned above, the SR-IOV devices just get their PCI topology or slot name, not the name of the parent device, and therefore they do not run into the too long names. You take 2 to define the interface type (en,wl,ww), leaving 4 to describe the PCI topology. Not gonna fit... It fits, if we don't do the pretty name thing biosdevname does. And last time I looked, we can't make IFNAMESIZ bigger, as it's kernel ABI to userspace and used in a ton of places. Yeah, we cannot change that fact. This is why the biosdevname naming convention is not as pretty as yours Well, the biosdevname names are surely prettier than the udev ones. But the udev ones are predictable and have only one device to look at, when the name is composed. There is zero other logic, that would involve any global view of the system, or look at sibling devices; hence the uglier, but more robust names. there simply isn't enough space in IFNAMSIZ to do much given the claims already on the space that we can't ignore. We can't solve that, so we won't is not acceptable. Real people use these network features every day. The compromise of biosdevname to make pretty names, like using shorter numbers, or use the parent device as the basename for related devices, are done at the cost of general reliability and dependence of crawling the entire device tree to get a system overview, and make assumptions based on the existence of other devices. We liked the names biosdevname did, and wanted to do the same, but udev just cannot do that, it is too fragile in hotplug setups to look at anything but the device that is currently handled. E) In this thread, it has come up several times that biosdevname falls back to an emumeration method in some cases where the BIOS information is not present. Yes, it does, though there are command line flags that can disable that in general (e.g. --smbios26 means it won't trigger unless the info is present in firmware). Well, as always, defaults matter, not options in tools. And the defaults of biosdevname did that guessing thing, which does not sound right. As I've handed of maintenance of biosdevname to a whole engineering team, I don't know the current state of any other enumeration codepaths, but I agree, that's a lousy way to get the right answer, and I'm sure the engineering team would take suggestions on how to fix it, rather than 'throw out the baby with the bathwater'. I think userspace enumeration as a general concept to start with cannot work on today's systems. With a few exceptions, no device naming should ever look at other devices for its own name, it's a model that will break in many weird ways. F) sane (to a programmer) PCI bus topology is getting more and more difficult to come by, as multiple PCI roots now hang off specific CPUs. It will not be unusual for embedded devices to hang off the second
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 02/05/2013 02:53 AM, Scott Schmit wrote: Is there a program/script we can run that would tell us what the interface names would be without biosdevname (without running the new version of systemd on the box)? If you have Fedora 18 with updates applied your systemd is new enough to allow you to see the udev-generated names using: udevadm info --export -p /sys/class/net/$IFACE | grep ID_NET Example output: E: ID_NET_NAME_MAC=enx000f53014229 E: ID_NET_NAME_PATH=enp40s0f1d1 E: ID_NET_NAME_SLOT=ens4f1d1 Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 2-6-13 14:33:42 Michal Schmidt wrote: If you have Fedora 18 with updates applied your systemd is new enough to allow you to see the udev-generated names using: udevadm info --export -p /sys/class/net/$IFACE | grep ID_NET Example output: E: ID_NET_NAME_MAC=enx000f53014229 E: ID_NET_NAME_PATH=enp40s0f1d1 E: ID_NET_NAME_SLOT=ens4f1d1 One (probably very common) data point, then: garry@vfr$ lspci|grep Ethernet 00:19.0 Ethernet controller: Intel Corporation 82562V 10/100 Network Connection (rev 02) garry@vfr$ udevadm info --export -p /sys/class/net/em1 | grep ID_NET E: ID_NET_NAME_MAC=enx0019d1726ba9 E: ID_NET_NAME_PATH=enp0s25 garry@vfr$ -- Garry T. Williams -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
I haven't chimed in on this thread yet, and as the original biosdevname author, I suppose I should. Some points of consideration, which I had shared with Lennart and Kay when they first showed me their work. A) I'm glad to see someone else recognize and want to tackle this. Doing it in udev makes a lot of sense, and will certainly force more distros and hardware vendors to use it. RHEL6 still has it enabled only for Dell systems, by request of (other hardware vendors) who didn't want to inflict biosdevname on their users. We will need a method to enable/disable on a per-vendor basis as we added to RHEL in the udev rules that invoke (or don't) biosdevname. The suggestion of linking in (or not) rules files won't work for a distro-wide per-vendor configuration. B) I have had far more positive feedback about the effectiveness of biosdevname from Dell customers than I have negative. They love that finally the physical external chassis labels have a direct correlation to the Linux (and Windows Server 2012 if you're counting) device name. C) There are several cases that biosdevname handles that udev doesn't (yet) - NPAR and SR-IOV at least. These are widely used in Dell and other vendors' servers. D) the udev scheme will run out of characters in IFNAMSIZ (you've got at most 15 chars to work with, really less 5 because decimal-based VLAN tagging is allowed, hence MAC-based won't fit). Once you allow NPAR/SR-IOV you need at least 4 characters there (e.g. i254 as suffix), leaving you with 6 usable. You take 2 to define the interface type (en,wl,ww), leaving 4 to describe the PCI topology. Not gonna fit... And last time I looked, we can't make IFNAMESIZ bigger, as it's kernel ABI to userspace and used in a ton of places. This is why the biosdevname naming convention is not as pretty as yours - there simply isn't enough space in IFNAMSIZ to do much given the claims already on the space that we can't ignore. We can't solve that, so we won't is not acceptable. Real people use these network features every day. E) In this thread, it has come up several times that biosdevname falls back to an emumeration method in some cases where the BIOS information is not present. Yes, it does, though there are command line flags that can disable that in general (e.g. --smbios26 means it won't trigger unless the info is present in firmware). As I've handed of maintenance of biosdevname to a whole engineering team, I don't know the current state of any other enumeration codepaths, but I agree, that's a lousy way to get the right answer, and I'm sure the engineering team would take suggestions on how to fix it, rather than 'throw out the baby with the bathwater'. F) sane (to a programmer) PCI bus topology is getting more and more difficult to come by, as multiple PCI roots now hang off specific CPUs. It will not be unusual for embedded devices to hang off the second CPU slot, which may or may not be populated with a CPU. We're long past the days where I can convince any motherboard designers to physically route their boards to bring sanity to OS device naming schemes. So, in short, I support making Consistent Network Device Names better. But I'm not convinced the udev proposal is the right solution. I'd like to see an analysis of what I got wrong in biosdevname, proposals to fix those that don't cause even more problems, and then come to a solution. I expect Lennart and Kay have already done this, but the only argument I keep hearing on this thread is biosdevname sometimes does enumeration of its own - that's evil which is correct, but not sufficient justification to throw it out. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO pgp_g0s6eanZ7.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Feb 04, 2013 at 03:03:08PM +0100, Kay Sievers wrote: On Thu, Jan 31, 2013 at 2:45 PM, Scott Schmit wrote: Current: em1 - enp2s0 That is expected, and actually the right thing to do. Udev cannot apply such it looks like it is embedded heuristics for very practical technical reasons. There is no reliable information about that on the system, so this logic will break sooner or later. There is also no sane way to share the namespace with the embedded interface indices defined by the firmware. It should never have been done by biosdevname that way. em2 - eno1 em3 - eno2 Ouch, is that really the case? If that's what you see on your box, then biosdevname would have invented its own numbers for the *fixed* SMBIOS provided index numbers, and rebased them to something different. That would be really weird. This isn't a real life example, this was just an example of something I could imagine happening that would screw people up, based on what I thought I understood from the list (even your response to the first part implies that some machines could have real embedded devices mixed with pseudo-embedded devices, but your response to the second implies otherwise, so I don't know what to make of that...). Is there a program/script we can run that would tell us what the interface names would be without biosdevname (without running the new version of systemd on the box)? Not that that would tell me what to expect for other people, but I suppose if a bunch of people looked at what it did to their box(es) and somebody saw something surprising, they could speak up. (Assuming they knew what surprising looked like...) :-) -- Scott Schmit smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Jan 31, 2013 at 2:45 PM, Scott Schmit i.g...@comcast.net wrote: Current: em1 - enp2s0 That is expected, and actually the right thing to do. Udev cannot apply such it looks like it is embedded heuristics for very practical technical reasons. There is no reliable information about that on the system, so this logic will break sooner or later. There is also no sane way to share the namespace with the embedded interface indices defined by the firmware. It should never have been done by biosdevname that way. em2 - eno1 em3 - eno2 Ouch, is that really the case? If that's what you see on your box, then biosdevname would have invented its own numbers for the *fixed* SMBIOS provided index numbers, and rebased them to something different. That would be really weird. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Jan 29, 2013 at 01:58:30PM -0500, Bill Nottingham wrote: Tomasz Torcz (to...@pipebreaker.pl) said: It might be worth considering that we keep the one special case and change the 'eno' prefix in udev to 'em'... this will help some. This could be dangerous. If I understand right, there is not guarantee em1 would become eno1 in 100% of cases. Iptables saved config would still need to be checked and verified. It won't, but having it be the same in the case where it *does* have the same idea as biosdevname of 'first embedded interface', it could be useful to have the same name. Well, of course. But in the happy path, everything always works. :) I know that on my computers, I've only ever had one em1, but a) it's not clear to me whether my em1's will translate to eno1 or to some enp0s0 name b) I'm not sure that I'm typical. As they say, the plural of anecdote isn't data. In the cases where there are multiple em*, some of which will no longer be considered embedded things get nasty. In the current proposal, stuff will outright break because there's no match. With the proposed compatibility names, things could seem to work at first and only later is the damage realized. Example: Current: em1 - enp2s0 em2 - eno1 em3 - eno2 Now with compatibility: em1 - enp2s0 em2 - em1 em3 - em2 Say that em1 is external traffic (hardened rules), em2 is management traffic (allows ssh/pretty much anything), and em3 is internal traffic (no ssh, etc). Sure, there's some breakage here, so they probably won't miss that the em2's shifted, but it's possible they'll miss a config or two specific to em2. This is also a case where keeping the em prefix didn't really help anybody out anyway (and makes it harder to search replace -- is that the old em2 or the new em2?). If we can be sure that this sort of shifting will be rare, then sure, keeping em* is helpful. If we can't, we're creating headaches. Change is hard, no matter what, but let's be careful who we're really helping (the user with only one embedded interface that maybe never notices anyway or the admin with multiple embedded interfaces for whom the above scenario is actually worse?). I don't have data of which is better, but I thought I'd point the conflict out. IMHO, the fact that this affects wlan* is going to be more painful. It took me some time to re-train my fingers to stop typing eth1 when I wanted wlan0, but it was really nice knowing on a new laptop which was which. (I'm not saying we need to keep wlan0, but prefixing with wl instead of en might be better.) I'll admit that GNOME 3 / the installer hide the names now, but when I upgraded from Fedora 16 to Fedora 17, dhcp4 broke I had to set up my network interface manually until I could get the appropriate packages updated -- knowing which was my wired interface was really helpful then! (And yes, upgrades don't rename anything. Imagine it was a 19 - 20 upgrade with the same problem.) -- Scott Schmit smime.p7s Description: S/MIME cryptographic signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Am 29.01.2013 19:38, schrieb Matthew Garrett: On Tue, Jan 29, 2013 at 12:32:30PM -0600, Dan Williams wrote: Except then you run into phones or WWAN cards that show up as Ethernet devices, but aren't really Ethernet but just IP-in-8023-frames because that was easier to do on Windows. That one is quite fun, and there's no good way to catch them all. We're obviously behind by marking them FLAG_WWAN in the kernel, which has to be done by device IDs, becasue some devices use standard cdc-ether or cdc-eem and you can't reliably tell them apart from some random D-Link DUB100. Sure, but that's a fundamentally unsolvable problem - if my primary network connection is via a USB device there's a reasonable chance that it'll be called usb0 anyway. The name isn't providing extra information here however, as long on virtual machines with ONE network card get a random name PLEASE leave me in peace with this feature as also biosdevname did not provide any benefit for such machines with 1-2 network devices [root@rawhide ~]# ifconfig ens160: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1500 inet 192.168.196.18 netmask 255.255.255.0 broadcast 192.168.196.255 inet6 fe80::20c:29ff:fe85:353c prefixlen 64 scopeid 0x20link ether 00:0c:29:85:35:3c txqueuelen 1000 (Ethernet) RX packets 169 bytes 17562 (17.1 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 123 bytes 15292 (14.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73UP,LOOPBACK,RUNNING mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10host loop txqueuelen 0 (Lokale Schleife) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Fri, Jan 25, 2013 at 4:25 PM, Marcela Mašláňová mmasl...@redhat.com wrote: On 01/25/2013 12:17 AM, Adam Williamson wrote: On Thu, 2013-01-24 at 23:03 +, Jóhann B. Guðmundsson wrote: It's best to rip the bandage of this in one release. The churn from this should have been more or less covered when we implement biosdevname so the fallout from this change should be minimal if any... I see the 's' word in there ;) That's always the hope, and then we meet the cold reality, where someone just patched 'em1' into everything and hoped that was good enough. But sure, 'damn the torpedoes' is a viable approach too. I guess I was just kind of hoping F19 would be a release without yet more churn in the core system where we could try and stabilize things a bit. I agree. The scope says no impact, but who knows how many packages depend on hardcoded names. It's not only em1 mistakenly hard-coded in applications; it's user's saved configuration, scripts etc., where often there is no practical alternative to hard-coding. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Jan 29, 2013 at 06:20:20PM +0100, Miloslav Trmač wrote: It's not only em1 mistakenly hard-coded in applications; it's user's saved configuration, scripts etc., where often there is no practical alternative to hard-coding. Right; people who just converted all of their stuff to use this will now have to go through and do it again. This does not make happy users and should be avoided when possible; that's why I advocated for keeping the naming scheme the same. But, if there are really technical advantages to the new approach, hey, we're Fedora. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 01/29/2013 05:20 PM, Miloslav Trmač wrote: On Fri, Jan 25, 2013 at 4:25 PM, Marcela Mašláňová mmasl...@redhat.com wrote: On 01/25/2013 12:17 AM, Adam Williamson wrote: On Thu, 2013-01-24 at 23:03 +, Jóhann B. Guðmundsson wrote: It's best to rip the bandage of this in one release. The churn from this should have been more or less covered when we implement biosdevname so the fallout from this change should be minimal if any... I see the 's' word in there ;) That's always the hope, and then we meet the cold reality, where someone just patched 'em1' into everything and hoped that was good enough. But sure, 'damn the torpedoes' is a viable approach too. I guess I was just kind of hoping F19 would be a release without yet more churn in the core system where we could try and stabilize things a bit. I agree. The scope says no impact, but who knows how many packages depend on hardcoded names. It's not only em1 mistakenly hard-coded in applications; it's user's saved configuration, scripts etc., where often there is no practical alternative to hard-coding. Mirek For the first how many users did you notice complaining about the biosdevice name change, secondly are you seriously saying that if I have a local script as in nothing we ship we just hold the presses and nothing in the project can be moved forward unless it's backward compatible to my script? That's just nonsense. It's my responsibility to read the release notes or otherwise keep myself informed of any changes and keep *my* scripts updated but it's the project responsability to try to keep anything we ship from breaking as an result of any changes we make. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Miloslav Trmač (m...@volny.cz) said: That's always the hope, and then we meet the cold reality, where someone just patched 'em1' into everything and hoped that was good enough. But sure, 'damn the torpedoes' is a viable approach too. I guess I was just kind of hoping F19 would be a release without yet more churn in the core system where we could try and stabilize things a bit. I agree. The scope says no impact, but who knows how many packages depend on hardcoded names. It's not only em1 mistakenly hard-coded in applications; it's user's saved configuration, scripts etc., where often there is no practical alternative to hard-coding. I would assume that it would only be for new installs, not for upgrades. It might be worth considering that we keep the one special case and change the 'eno' prefix in udev to 'em'... this will help some. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Jan 29, 2013 at 6:35 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: For the first how many users did you notice complaining about the biosdevice name change, secondly are you seriously saying that if I have a local script as in nothing we ship we just hold the presses and nothing in the project can be moved forward unless it's backward compatible to my script? That's just nonsense. It's my responsibility to read the release notes or otherwise keep myself informed of any changes and keep *my* scripts updated but it's the project responsability to try to keep anything we ship from breaking as an result of any changes we make. It's not that black and white. Sure, we can change things, and sure, sometimes the users will have to work to migrate. Still, the easier it is to migrate, the better off our users will be, so we should think hard both about how avoid changing user interfaces (using the term _very_ loosely), and how to design the new user interfaces so that changes are no longer as disruptive. In this case, a possible example is the migration to firewalld, where a lot of firewall configuration that used to directly embed interface names can instead be tied to a zone, with only one place where the network interface-zone mapping needs to be modified. So, in a sense, the F18/F19 transition is a better time to rename network interfaces than the F17/F18 transition would have been. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, 29.01.13 18:20, Miloslav Trmač (m...@volny.cz) wrote: On Fri, Jan 25, 2013 at 4:25 PM, Marcela Mašláňová mmasl...@redhat.com wrote: On 01/25/2013 12:17 AM, Adam Williamson wrote: On Thu, 2013-01-24 at 23:03 +, Jóhann B. Guðmundsson wrote: It's best to rip the bandage of this in one release. The churn from this should have been more or less covered when we implement biosdevname so the fallout from this change should be minimal if any... I see the 's' word in there ;) That's always the hope, and then we meet the cold reality, where someone just patched 'em1' into everything and hoped that was good enough. But sure, 'damn the torpedoes' is a viable approach too. I guess I was just kind of hoping F19 would be a release without yet more churn in the core system where we could try and stabilize things a bit. I agree. The scope says no impact, but who knows how many packages depend on hardcoded names. It's not only em1 mistakenly hard-coded in applications; it's user's saved configuration, scripts etc., where often there is no practical alternative to hard-coding. BTW: We have now updated the feature page to ask for removal of biosdevname from comps, as the discussions on fedora-devel kinda indicated that that'd be a good idea. We also added as optional part to the feature that we can disable the new rules on upgrade, so that the naming scheme stays unaltered on upgrades, even on systems where biosdevname was not installed before, and where fixed interface names were not in the network configuration files. We don't really like the implications of such a logic of disabling new features on upgrades, since that has the nasty effect that first installing version A of a package and then upgrading to B has a completely different effect than installing B right-away, but we don't really have any nice other idea either. We hence added this as optional part to the spec and would like to ask FESCO to decide on this at the same time as discussing the feature's overall merits. Or in other words, we'd like one of three answers from FESCO: a) feature declined, b) feature accepted but leave the new logic off on upgrades, c) feature accepted but enable it on upgrades too. I hope this makes sense, Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Jan 29, 2013 at 06:20:20PM +0100, Miloslav Trmač wrote: It's not only em1 mistakenly hard-coded in applications; it's user's saved configuration, scripts etc., where often there is no practical alternative to hard-coding. I created a bug report about this issue: https://bugzilla.redhat.com/show_bug.cgi?id=700933 I suppose I could have written a script that goes through the list of interfaces, filters out hardcoded names like lo, wlan, tun, and tap, and then assumes that whatever is left is the ethernet device. And then I could have fixed such a script each time it breaks when types of devices are added and renamed (surely the current discussion is only the next phase in a long sequence of renames). In the end, though, I just disabled biosdevname. Having a static eth0 name is much less brittle, even on many multi-interface machines. I'm a little uncomfortable with the apparently prevalent idea that having complicated names for ethernet devices is better for all users in all situations. I'm sure that in some situations it's nice and helpful, but in others, it's harmful. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Jan 29, 2013 at 12:05:44PM -0600, Andrew McNabb wrote: I suppose I could have written a script that goes through the list of interfaces, filters out hardcoded names like lo, wlan, tun, and tap, and then assumes that whatever is left is the ethernet device. And then I could have fixed such a script each time it breaks when types of devices are added and renamed (surely the current discussion is only the next phase in a long sequence of renames). In the end, though, I just disabled biosdevname. Having a static eth0 name is much less brittle, even on many multi-interface machines. Walk /sys/class/net, filter on type, filter out bridges, filter out wireless if you want to. sysfs should have all the information you need without name-based heuristics. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 01/29/2013 01:13 PM, Andrew McNabb wrote: On Tue, Jan 29, 2013 at 06:11:19PM +, Matthew Garrett wrote: Walk /sys/class/net, filter on type, filter out bridges, filter out wireless if you want to. sysfs should have all the information you need without name-based heuristics. You have added confirmation that any attempt to figure out the name of the interface is an ugly brittle mess. ;) -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 I agree. I was so happy when we moved from FreeBSD with its em's, vr's, rl's, re's, bge's, fxp's, ed's, etc to Linux with just eth! -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Jan 29, 2013 at 12:13:37PM -0600, Andrew McNabb wrote: On Tue, Jan 29, 2013 at 06:11:19PM +, Matthew Garrett wrote: Walk /sys/class/net, filter on type, filter out bridges, filter out wireless if you want to. sysfs should have all the information you need without name-based heuristics. You have added confirmation that any attempt to figure out the name of the interface is an ugly brittle mess. ;) What is The ethernet device? It's the device that speaks ethernet and which isn't wireless or a bridge. The correct way to identify it is to look for devices that speak ethernet and which aren't wireless or bridges. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, 2013-01-29 at 18:29 +, Matthew Garrett wrote: On Tue, Jan 29, 2013 at 12:13:37PM -0600, Andrew McNabb wrote: On Tue, Jan 29, 2013 at 06:11:19PM +, Matthew Garrett wrote: Walk /sys/class/net, filter on type, filter out bridges, filter out wireless if you want to. sysfs should have all the information you need without name-based heuristics. You have added confirmation that any attempt to figure out the name of the interface is an ugly brittle mess. ;) What is The ethernet device? It's the device that speaks ethernet and which isn't wireless or a bridge. The correct way to identify it is to look for devices that speak ethernet and which aren't wireless or bridges. Except then you run into phones or WWAN cards that show up as Ethernet devices, but aren't really Ethernet but just IP-in-8023-frames because that was easier to do on Windows. That one is quite fun, and there's no good way to catch them all. We're obviously behind by marking them FLAG_WWAN in the kernel, which has to be done by device IDs, becasue some devices use standard cdc-ether or cdc-eem and you can't reliably tell them apart from some random D-Link DUB100. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Jan 29, 2013 at 12:32:30PM -0600, Dan Williams wrote: Except then you run into phones or WWAN cards that show up as Ethernet devices, but aren't really Ethernet but just IP-in-8023-frames because that was easier to do on Windows. That one is quite fun, and there's no good way to catch them all. We're obviously behind by marking them FLAG_WWAN in the kernel, which has to be done by device IDs, becasue some devices use standard cdc-ether or cdc-eem and you can't reliably tell them apart from some random D-Link DUB100. Sure, but that's a fundamentally unsolvable problem - if my primary network connection is via a USB device there's a reasonable chance that it'll be called usb0 anyway. The name isn't providing extra information here. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Jan 29, 2013 at 06:29:35PM +, Matthew Garrett wrote: What is The ethernet device? It's the device that speaks ethernet and which isn't wireless or a bridge. The correct way to identify it is to look for devices that speak ethernet and which aren't wireless or bridges. I can pretty much guarantee that I would not implement this correctly the first time. If there were an official tool for doing this, it would take the edge off the rename churning that's been going on for the last few years. I've hit too many renaming-related bugs to get excited about yet another attempt. On 90% of computers, eth0 is it, and all of this complicated stuff just makes it worse. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Jan 29, 2013 at 12:46:29PM -0500, Bill Nottingham wrote: Miloslav Trmač (m...@volny.cz) said: That's always the hope, and then we meet the cold reality, where someone just patched 'em1' into everything and hoped that was good enough. But sure, 'damn the torpedoes' is a viable approach too. I guess I was just kind of hoping F19 would be a release without yet more churn in the core system where we could try and stabilize things a bit. I agree. The scope says no impact, but who knows how many packages depend on hardcoded names. It's not only em1 mistakenly hard-coded in applications; it's user's saved configuration, scripts etc., where often there is no practical alternative to hard-coding. I would assume that it would only be for new installs, not for upgrades. Upgrades will retain biosdevname package, so names shouldn't change. It might be worth considering that we keep the one special case and change the 'eno' prefix in udev to 'em'... this will help some. This could be dangerous. If I understand right, there is not guarantee em1 would become eno1 in 100% of cases. Iptables saved config would still need to be checked and verified. -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Tomasz Torcz (to...@pipebreaker.pl) said: It might be worth considering that we keep the one special case and change the 'eno' prefix in udev to 'em'... this will help some. This could be dangerous. If I understand right, there is not guarantee em1 would become eno1 in 100% of cases. Iptables saved config would still need to be checked and verified. It won't, but having it be the same in the case where it *does* have the same idea as biosdevname of 'first embedded interface', it could be useful to have the same name. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, 2013-01-29 at 18:38 +, Matthew Garrett wrote: On Tue, Jan 29, 2013 at 12:32:30PM -0600, Dan Williams wrote: Except then you run into phones or WWAN cards that show up as Ethernet devices, but aren't really Ethernet but just IP-in-8023-frames because that was easier to do on Windows. That one is quite fun, and there's no good way to catch them all. We're obviously behind by marking them FLAG_WWAN in the kernel, which has to be done by device IDs, becasue some devices use standard cdc-ether or cdc-eem and you can't reliably tell them apart from some random D-Link DUB100. Sure, but that's a fundamentally unsolvable problem - if my primary network connection is via a USB device there's a reasonable chance that it'll be called usb0 anyway. The name isn't providing extra information here. Actually usbnet uses this logic: usb%d = default eth%d = FLAG_ETHER !FLAG_POINTTOPOINT !(dev_addr[0] 0x02) wlan%d = FLAG_WLAN wwan%d = FLAG_WWAN so it's really a crapshoot depending on kernel version and which devices have been flagged explicitly. Some classes of device will get usb0 and some with get eth0 and there's no really clear line about which ones are actually really ethernet and which are pseduo-ethernet. Also, 'ipeth' (iPhone USB ethernet tethering) uses eth%d. Go figure. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Tue, Jan 29, 2013 at 12:46:29PM -0500, Bill Nottingham wrote: It might be worth considering that we keep the one special case and change the 'eno' prefix in udev to 'em'... this will help some. Yes! Very much! Not only will this practically easy things, it shifts the perception from And we're changin' it all up again! to It's a refinement of the previous way. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 01/25/2013 04:25 PM, Marcela Mašláňová wrote: I agree. The scope says no impact, but who knows how many packages depend on hardcoded names. I hope most of them has been already fixed with https://bugzilla.redhat.com/show_bug.cgi?id=682334 -- Jiri -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Le lundi 28 janvier 2013 à 10:49 +0100, Jiri Popelka a écrit : On 01/25/2013 04:25 PM, Marcela Mašláňová wrote: I agree. The scope says no impact, but who knows how many packages depend on hardcoded names. I hope most of them has been already fixed with https://bugzilla.redhat.com/show_bug.cgi?id=682334 Given that the various BSDs use a totally different naming convention than Linux ( ie, based on the driver used ), the list should not be so big for portable applications. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Oron Peled (o...@actcom.co.il) said: IMO, my following proposal is only feasible if (and it's a big iff), the number of system calls and library functions that accept a network interface name is not large [things like if_nameindex(), the ifreq ioctl()'s, etc.] If that's the case, we can map predictable names to traditional ones in user-space, on the entry to said library functions, or entry to the said glibc syscall wrappers. The problem is that explicitly because network devices have never been enumerable in /dev before, every single utility does it themeselves. Mostly by trawling /sysfs these days, but still... attempting to move to an alternate naming scheme library could/would break everything that only knows how to enumerate the kernel devices. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Jiri Popelka (jpope...@redhat.com) said: On 01/25/2013 04:25 PM, Marcela Mašláňová wrote: I agree. The scope says no impact, but who knows how many packages depend on hardcoded names. I hope most of them has been already fixed with https://bugzilla.redhat.com/show_bug.cgi?id=682334 We could certainly explode and scan the code again if need be. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Sun, 27.01.13 01:06, Oron Peled (o...@actcom.co.il) wrote: On Wednesday 23 January 2013 23:49:48 Kay Sievers wrote: ... We had no better idea really, than to copy the successful model we do for disks (and other subsystems) with /dev/disk/by-*/ symlinks. It was a well-known scheme, but it was certainly not know for network devices so far. So we picked up the basic ideas from biosdevname and combined them with the proven scheme we do for all other subsystems in udev. This necessarily lead to different names, but from udev's point of view they are entirely justified. The /dev/disk/... is nice because of *two* properties: * It indeed provides unique, persistent names * But people can still use /dev/sda Which is useful in the super-common case of single disk PC I.e: the predictable names are just aliases for the traditional names. In another mail on this thread, someone mentioned that this possibility was looked into, but the related kernel code cannot be easily modified to support multiple-names per interface. However, maybe implementing this aliasing in user-space is more tractable? IMO, my following proposal is only feasible if (and it's a big iff), the number of system calls and library functions that accept a network interface name is not large [things like if_nameindex(), the ifreq ioctl()'s, etc.] If that's the case, we can map predictable names to traditional ones in user-space, on the entry to said library functions, or entry to the said glibc syscall wrappers. Example of a possible mapping scheme: * Have udev create a symlink that maps the predictable name into the string of the traditional name. E.g: /dev/netdev/enp2s0 - eth0 * Of course, there's no eth0 file, but nevertheless the symlink can contain this string. * Now implement ifname_mapto(const char *name, char *new_name) as follows: - If there's no /dev/netdev/name, use name as new_name (identity) - Otherwise, new_name is the result of readlink(/dev/netdev/name) Now if there aren't zillions of functions that process network interface names, modifying them seems reasonable. The advantage is that it allows the use the traditional names for the most common cases (e.g: a laptop with one eth0 and one wlan0) while still providing a predictable naming to be used when needed. Actually there quite a few of kernel-level interfaces that expose interface names, and applications use them. There's netlink, there are the ioctl()s, there is /sys, there's /proc/sys, and there's more. For many of those interfaces the libc doesn't even know that has something to do with networking. Hence: if people want aliasing, this would have to happen in the kernel, but even then it's really complex, since many apis don't really cater for that, and this would mean breakage. We figured in this it's better to just stick to a single name for each iface, pick a good default scheme for it, and support alternative schemes. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Jan 25, 2013 3:45 PM, Marcela Mašláňová mmasl...@redhat.com wrote: On 01/25/2013 12:17 AM, Adam Williamson wrote: On Thu, 2013-01-24 at 23:03 +, Jóhann B. Guðmundsson wrote: It's best to rip the bandage of this in one release. The churn from this should have been more or less covered when we implement biosdevname so the fallout from this change should be minimal if any... I see the 's' word in there ;) That's always the hope, and then we meet the cold reality, where someone just patched 'em1' into everything and hoped that was good enough. But sure, 'damn the torpedoes' is a viable approach too. I guess I was just kind of hoping F19 would be a release without yet more churn in the core system where we could try and stabilize things a bit. I agree. The scope says no impact, but who knows how many packages depend on hardcoded names. I guess we just have to cross that bridge when we get there... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wednesday 23 January 2013 23:49:48 Kay Sievers wrote: ... We had no better idea really, than to copy the successful model we do for disks (and other subsystems) with /dev/disk/by-*/ symlinks. It was a well-known scheme, but it was certainly not know for network devices so far. So we picked up the basic ideas from biosdevname and combined them with the proven scheme we do for all other subsystems in udev. This necessarily lead to different names, but from udev's point of view they are entirely justified. The /dev/disk/... is nice because of *two* properties: * It indeed provides unique, persistent names * But people can still use /dev/sda Which is useful in the super-common case of single disk PC I.e: the predictable names are just aliases for the traditional names. In another mail on this thread, someone mentioned that this possibility was looked into, but the related kernel code cannot be easily modified to support multiple-names per interface. However, maybe implementing this aliasing in user-space is more tractable? IMO, my following proposal is only feasible if (and it's a big iff), the number of system calls and library functions that accept a network interface name is not large [things like if_nameindex(), the ifreq ioctl()'s, etc.] If that's the case, we can map predictable names to traditional ones in user-space, on the entry to said library functions, or entry to the said glibc syscall wrappers. Example of a possible mapping scheme: * Have udev create a symlink that maps the predictable name into the string of the traditional name. E.g: /dev/netdev/enp2s0 - eth0 * Of course, there's no eth0 file, but nevertheless the symlink can contain this string. * Now implement ifname_mapto(const char *name, char *new_name) as follows: - If there's no /dev/netdev/name, use name as new_name (identity) - Otherwise, new_name is the result of readlink(/dev/netdev/name) Now if there aren't zillions of functions that process network interface names, modifying them seems reasonable. The advantage is that it allows the use the traditional names for the most common cases (e.g: a laptop with one eth0 and one wlan0) while still providing a predictable naming to be used when needed. Now, what do my .signature try to tell me? ;-) -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron ... Complex problems have simple, easy to understand wrong answers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Jan 24, 2013 at 11:32:31PM +0100, Lennart Poettering wrote: One problem with biosdevname is that it uses different naming schemes in the same namespace. For us, predictability means that by looking at the lspci or DMI information of your card you can deterministically figure out how your network interface is going to be named, but also the reverse, that by looking at an interface name you can figure out where precisely the data came from. With biosdevname' scheme you cannot do that as using different enumeration within the same namespace might result in name clashes, and hence we think it's a good idea to stay away from the old namespace. This has a flipside: devices are likely to have similar names regardless of hardware details. This makes it easier to manage heterogeneous (i.e., real world) datacenters. That's not a primary use case for Fedora, but it sure is for our downstream distributions. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 01/25/2013 12:17 AM, Adam Williamson wrote: On Thu, 2013-01-24 at 23:03 +, Jóhann B. Guðmundsson wrote: It's best to rip the bandage of this in one release. The churn from this should have been more or less covered when we implement biosdevname so the fallout from this change should be minimal if any... I see the 's' word in there ;) That's always the hope, and then we meet the cold reality, where someone just patched 'em1' into everything and hoped that was good enough. But sure, 'damn the torpedoes' is a viable approach too. I guess I was just kind of hoping F19 would be a release without yet more churn in the core system where we could try and stabilize things a bit. I agree. The scope says no impact, but who knows how many packages depend on hardcoded names. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Jan 24, 2013 at 12:28:59AM +0100, Lennart Poettering wrote: That inventing your own numbering is a problem manifests itself in bugs like this: https://bugzilla.redhat.com/show_bug.cgi?id=782145#c21 Okay, I can see that. Still, I wish there were a greater attempt to maintain similar naming where possible. This sort of churn is expensive. Well, the page says high-level UIs. The GNOME3 UI certainly doesn't expose the interface name anywhere, does it? It does if you click around enough. And I haven't tried Gnome 3 on a system with multiple ethernet cards, but I would hope that _somewhere_ it would tell me which was which. But I guess we simply have a different definition of a user here. Your definition is probably closer to what the page calls admins, which is covered by the next lines in the feature page, which you didn't paste: Right. For Fedora, developers and admins are an important subset of users. As biosdevname is installed by default ... most administrators won't see this either. If the new scheme really is better, we should suck it up and make the whole change. It'd be better to do what we can to make that transition easier -- like using similar names were possible -- than to have a weird mixed state. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 01/23/2013 01:54 PM, Bill Nottingham wrote: This code has the benefit of: - covering more device types (not just BIOSes with type 9 type 41) - not attempting to do heuristics that name devices via enumeration However, it does have the large disadvantage of changing the namespace used. Another cause for concern by users is the maintenance record of systemd: https://bugzilla.redhat.com/show_bug.cgi?id=841822 pungi can't create installable media with F17 + updates For about five months from July through December 2012 a bug in systemd-44-17.fc17 prevented installation of Fedora 17 using an updated .iso/DVD/USB containing the then-current packages. Obviously there were workarounds, but the long persistence of the bug was irksome and slowed the adoption of Fedora 17. The root cause was identified in just a few days: https://bugzilla.redhat.com/show_bug.cgi?id=841822#c9 but the fix for Fedora 17 did not appear despite gentle ping. Please pay more attention to maintenance of systemd. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 01/24/2013 03:17 PM, John Reiser wrote: On 01/23/2013 01:54 PM, Bill Nottingham wrote: This code has the benefit of: - covering more device types (not just BIOSes with type 9 type 41) - not attempting to do heuristics that name devices via enumeration However, it does have the large disadvantage of changing the namespace used. Another cause for concern by users is the maintenance record of systemd: https://bugzilla.redhat.com/show_bug.cgi?id=841822 pungi can't create installable media with F17 + updates For about five months from July through December 2012 a bug in systemd-44-17.fc17 prevented installation of Fedora 17 using an updated .iso/DVD/USB containing the then-current packages. Obviously there were workarounds, but the long persistence of the bug was irksome and slowed the adoption of Fedora 17. The root cause was identified in just a few days: https://bugzilla.redhat.com/show_bug.cgi?id=841822#c9 but the fix for Fedora 17 did not appear despite gentle ping. Please pay more attention to maintenance of systemd. The track record of systemd maintains is just fine better than many other components in the distribution. Claiming something else is just absurd. JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 01/24/2013 04:17 PM, John Reiser wrote: Another cause for concern by users is the maintenance record of systemd: https://bugzilla.redhat.com/show_bug.cgi?id=841822 pungi can't create installable media with F17 + updates For about five months from July through December 2012 The Bodhi page shows that systemd-44-20.fc17 with the fix was released in October, not December. Anyway, the bug simply did not appear that urgent to me. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, 24.01.13 07:17, John Reiser (jrei...@bitwagon.com) wrote: On 01/23/2013 01:54 PM, Bill Nottingham wrote: This code has the benefit of: - covering more device types (not just BIOSes with type 9 type 41) - not attempting to do heuristics that name devices via enumeration However, it does have the large disadvantage of changing the namespace used. Another cause for concern by users is the maintenance record of systemd: Oh, really? https://bugzilla.redhat.com/show_bug.cgi?id=841822 pungi can't create installable media with F17 + updates For about five months from July through December 2012 a bug in systemd-44-17.fc17 prevented installation of Fedora 17 using an updated .iso/DVD/USB containing the then-current packages. Obviously there were workarounds, but the long persistence of the bug was irksome and slowed the adoption of Fedora 17. The root cause was identified in just a few days: https://bugzilla.redhat.com/show_bug.cgi?id=841822#c9 but the fix for Fedora 17 did not appear despite gentle ping. Please pay more attention to maintenance of systemd. I am sorry, but I am actually kinda sure we (and particularly Michal) are doing a very good job there. The number of bugs is pretty low for such a basic component of this size, especially if you discount RFEs and suchlike. My guess is that there's simply a disparity between how important you considered that specific bug and how it appeared to us. Also note that the issue was not so clearly on systemd's side of things... Also, thanks for derailing the discussion with something totally unrelated. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Orion Poplawski (or...@cora.nwra.com) said: I'm not trying to disparage this work, it seems reasonable (although I've been bitten by a lot of crappy software assuming network devices are named eth#, but it's able to be turned off, so meh). We went through most of the things we shipped back when biosdevname was first introduced and filed a *lot* of bugs to get all those cases fixed, so we *should* be much better there. (Can't speak to third-party software, obviously). If any of those fixes involved merely adding the biosdevname namespaces to whitelists instead of properly getting device names, well, I'm not *supposed* to promote an attitude of violence, but... Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Matthew Miller (mat...@fedoraproject.org) said: But I guess we simply have a different definition of a user here. Your definition is probably closer to what the page calls admins, which is covered by the next lines in the feature page, which you didn't paste: Right. For Fedora, developers and admins are an important subset of users. As biosdevname is installed by default ... most administrators won't see this either. If the new scheme really is better, we should suck it up and make the whole change. It'd be better to do what we can to make that transition easier -- like using similar names were possible -- than to have a weird mixed state. So, thinking - if we were to go this route, I think we'd want a clean break, where we don't use biosdevname at all if we're using this. The simplest way to do that would be: - change biosdevname to not be installed by default - enable these rules only on install, not on upgrade both of which are pretty easily doable. To quote the documentation, of the device name formats: * Two character prefixes based on the type of interface: * en -- ethernet * wl -- wlan * ww -- wwan * * Type of names: * oindex -- on-board device index number * sslot[ffunction][ddev_id] -- hotplug slot index number * xMAC-- MAC address * pbussslot[ffunction][ddev_id] -- PCI geographical location * pbussslot[ffunction][uport][..][cconfig][iinterface] * -- USB port number chain What concerns would people have with this naming? Off the top of my head: - wwan devices aren't always discoverable (they can show up as ethernet) - devices that biosdevname considers emX via enumeration/guessing would now have enpXsY, which could be considered 'uglier' Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Jan 24, 2013 at 8:57 PM, Bill Nottingham nott...@redhat.com wrote: Matthew Miller (mat...@fedoraproject.org) said: But I guess we simply have a different definition of a user here. Your definition is probably closer to what the page calls admins, which is covered by the next lines in the feature page, which you didn't paste: Right. For Fedora, developers and admins are an important subset of users. As biosdevname is installed by default ... most administrators won't see this either. If the new scheme really is better, we should suck it up and make the whole change. It'd be better to do what we can to make that transition easier -- like using similar names were possible -- than to have a weird mixed state. So, thinking - if we were to go this route, I think we'd want a clean break, where we don't use biosdevname at all if we're using this. It's maybe a bit painful but might be the least confusing option. Ugh, that thing really seems to accelerate itself quite a bit. :) The simplest way to do that would be: - change biosdevname to not be installed by default - enable these rules only on install, not on upgrade both of which are pretty easily doable. To quote the documentation, of the device name formats: * Two character prefixes based on the type of interface: * en -- ethernet * wl -- wlan * ww -- wwan * * Type of names: * oindex -- on-board device index number * sslot[ffunction][ddev_id] -- hotplug slot index number * xMAC-- MAC address * pbussslot[ffunction][ddev_id] -- PCI geographical location * pbussslot[ffunction][uport][..][cconfig][iinterface] * -- USB port number chain What concerns would people have with this naming? Off the top of my head: - wwan devices aren't always discoverable (they can show up as ethernet) Yeah, it's not about discovery from userspace, we will not try that. It is directly exported by the kernel, the original name of that device was already wwan0. The kernel has netdev type names it exports like wlan, vlan, wwan. They are visible in sysfs, there is no logic really in userspace. - devices that biosdevname considers emX via enumeration/guessing would now have enpXsY, which could be considered 'uglier' Yeah, it's based on PCI IRQ table heurisitcs biosdevname does, with looking at bus == 0, and it starts counting at 1 all the devices there. We don't want to do that, and reserve the onboard names to actual real firmware records, and not base it on guesses. It's probably reasobably safe what biosdevname does in most cases, but we better do not get into that business and keep the safe, but granted, ugly name. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Jan 24, 2013 at 8:57 PM, Bill Nottingham nott...@redhat.com wrote: Matthew Miller (mat...@fedoraproject.org) said: But I guess we simply have a different definition of a user here. Your definition is probably closer to what the page calls admins, which is covered by the next lines in the feature page, which you didn't paste: Right. For Fedora, developers and admins are an important subset of users. As biosdevname is installed by default ... most administrators won't see this either. If the new scheme really is better, we should suck it up and make the whole change. It'd be better to do what we can to make that transition easier -- like using similar names were possible -- than to have a weird mixed state. So, thinking - if we were to go this route, I think we'd want a clean break, where we don't use biosdevname at all if we're using this. The simplest way to do that would be: - change biosdevname to not be installed by default - enable these rules only on install, not on upgrade both of which are pretty easily doable. To quote the documentation, of the device name formats: * Two character prefixes based on the type of interface: * en -- ethernet * wl -- wlan * ww -- wwan * * Type of names: * oindex -- on-board device index number * sslot[ffunction][ddev_id] -- hotplug slot index number * xMAC-- MAC address * pbussslot[ffunction][ddev_id] -- PCI geographical location * pbussslot[ffunction][uport][..][cconfig][iinterface] * -- USB port number chain What concerns would people have with this naming? Off the top of my head: - wwan devices aren't always discoverable (they can show up as ethernet) - devices that biosdevname considers emX via enumeration/guessing would now have enpXsY, which could be considered 'uglier' Do we actually need to change the naming of onboard devices from emN ? I wouldn't be surprised to see em1 hardcoded the same way eth0 used to be hardcoded. Getting rid of the type-dependent prefix would also resolve the wwan concern. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wed, Jan 23, 2013 at 8:59 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Features/SystemdPredictableNetworkInterfaceNames = https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames Feature owner(s): Kay Sievers kay at redhat dot com The udevd service has a long history of providing predicatable names for block devices and others. For Fedora 19 we'd like to provide the same for network interfaces, following a similar naming scheme, but only as fallback if not other solution such as biosdevname is installed or the administrator manually defined network interface names via udev rules or the old network scripts. 71-biosdevname.rules only handles KERNEL==eth*; so am I correct that it doesn't affect wlan* names at all? If wlan* is not controlled by biosdevname, what happens to them in this proposal in the default installation? Will they remain unchanged because biosdevname is installed, or will they be changed because biosdevname doesn't assign them a name? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, 24.01.13 22:28, Miloslav Trmač (m...@volny.cz) wrote: What concerns would people have with this naming? Off the top of my head: - wwan devices aren't always discoverable (they can show up as ethernet) - devices that biosdevname considers emX via enumeration/guessing would now have enpXsY, which could be considered 'uglier' Do we actually need to change the naming of onboard devices from emN ? One problem with biosdevname is that it uses different naming schemes in the same namespace. For us, predictability means that by looking at the lspci or DMI information of your card you can deterministically figure out how your network interface is going to be named, but also the reverse, that by looking at an interface name you can figure out where precisely the data came from. With biosdevname' scheme you cannot do that as using different enumeration within the same namespace might result in name clashes, and hence we think it's a good idea to stay away from the old namespace. I wouldn't be surprised to see em1 hardcoded the same way eth0 used to be hardcoded. Getting rid of the type-dependent prefix would also resolve the wwan concern. On upgrades biosdevname would stay installed, so if the old name is hardcoded it would still apply fine. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, 24.01.13 08:48, Matthew Miller (mat...@fedoraproject.org) wrote: As biosdevname is installed by default ... most administrators won't see this either. If the new scheme really is better, we should suck it up and make the whole change. It'd be better to do what we can to make that transition easier -- like using similar names were possible -- than to have a weird mixed state. Taking to account the feedback we git here and on various IRC channels we're now likely to change the feature a bit to also request removal of biosdevname from comps. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, 24.01.13 14:57, Bill Nottingham (nott...@redhat.com) wrote: Matthew Miller (mat...@fedoraproject.org) said: But I guess we simply have a different definition of a user here. Your definition is probably closer to what the page calls admins, which is covered by the next lines in the feature page, which you didn't paste: Right. For Fedora, developers and admins are an important subset of users. As biosdevname is installed by default ... most administrators won't see this either. If the new scheme really is better, we should suck it up and make the whole change. It'd be better to do what we can to make that transition easier -- like using similar names were possible -- than to have a weird mixed state. So, thinking - if we were to go this route, I think we'd want a clean break, where we don't use biosdevname at all if we're using this. The simplest way to do that would be: - change biosdevname to not be installed by default - enable these rules only on install, not on upgrade both of which are pretty easily doable. This is pretty much what both Gentoo and Arch decided to do (both of them already adopted the scheme for new installs). I am not too much of a fan of disable-something-on-upgrade schemes, but I guess if that's what it takes. Also I have no better idea... Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, 2013-01-24 at 14:57 -0500, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: But I guess we simply have a different definition of a user here. Your definition is probably closer to what the page calls admins, which is covered by the next lines in the feature page, which you didn't paste: Right. For Fedora, developers and admins are an important subset of users. As biosdevname is installed by default ... most administrators won't see this either. If the new scheme really is better, we should suck it up and make the whole change. It'd be better to do what we can to make that transition easier -- like using similar names were possible -- than to have a weird mixed state. So, thinking - if we were to go this route, I think we'd want a clean break, where we don't use biosdevname at all if we're using this. I am +1 to this in theory, but as Kay notes, it rather makes this a more prominent feature in practice. We've gone from 'effectively non-default brand new persistent naming scheme' to 'brand-new persistent naming scheme completely replacing all previous ones'. Which gives me something of a fit of wibbles. Is it worth at this point stepping back and asking whether this change is still appropriate for F19 as-is, or whether we should view the *final goal* as being to migrate wholesale to the new udev/systemd way of doing it, but maybe think about getting there in stages? This may wind up right back at the original proposal where we include the new method but don't make it the default for F19, but with a different outlook: the intent being to make it default for F20. At least we could try and get people to take a look at it first, that way. This code seems pretty new, and just dumping it straight in as default seems to risk going through exactly the same process biosdevname did. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Miloslav Trmač (m...@volny.cz) said: On Wed, Jan 23, 2013 at 8:59 PM, Jaroslav Reznik jrez...@redhat.com wrote: = Features/SystemdPredictableNetworkInterfaceNames = https://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames Feature owner(s): Kay Sievers kay at redhat dot com The udevd service has a long history of providing predicatable names for block devices and others. For Fedora 19 we'd like to provide the same for network interfaces, following a similar naming scheme, but only as fallback if not other solution such as biosdevname is installed or the administrator manually defined network interface names via udev rules or the old network scripts. 71-biosdevname.rules only handles KERNEL==eth*; so am I correct that it doesn't affect wlan* names at all? If wlan* is not controlled by biosdevname, what happens to them in this proposal in the default installation? Will they remain unchanged because biosdevname is installed, or will they be changed because biosdevname doesn't assign them a name? The latter. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 01/24/2013 10:43 PM, Adam Williamson wrote: On Thu, 2013-01-24 at 14:57 -0500, Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: But I guess we simply have a different definition of a user here. Your definition is probably closer to what the page calls admins, which is covered by the next lines in the feature page, which you didn't paste: Right. For Fedora, developers and admins are an important subset of users. As biosdevname is installed by default ... most administrators won't see this either. If the new scheme really is better, we should suck it up and make the whole change. It'd be better to do what we can to make that transition easier -- like using similar names were possible -- than to have a weird mixed state. So, thinking - if we were to go this route, I think we'd want a clean break, where we don't use biosdevname at all if we're using this. I am +1 to this in theory, but as Kay notes, it rather makes this a more prominent feature in practice. We've gone from 'effectively non-default brand new persistent naming scheme' to 'brand-new persistent naming scheme completely replacing all previous ones'. Which gives me something of a fit of wibbles. Is it worth at this point stepping back and asking whether this change is still appropriate for F19 as-is, or whether we should view the *final goal* as being to migrate wholesale to the new udev/systemd way of doing it, but maybe think about getting there in stages? This may wind up right back at the original proposal where we include the new method but don't make it the default for F19, but with a different outlook: the intent being to make it default for F20. At least we could try and get people to take a look at it first, that way. This code seems pretty new, and just dumping it straight in as default seems to risk going through exactly the same process biosdevname did. It's best to rip the bandage of this in one release. The churn from this should have been more or less covered when we implement biosdevname so the fallout from this change should be minimal if any... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, 2013-01-24 at 23:03 +, Jóhann B. Guðmundsson wrote: It's best to rip the bandage of this in one release. The churn from this should have been more or less covered when we implement biosdevname so the fallout from this change should be minimal if any... I see the 's' word in there ;) That's always the hope, and then we meet the cold reality, where someone just patched 'em1' into everything and hoped that was good enough. But sure, 'damn the torpedoes' is a viable approach too. I guess I was just kind of hoping F19 would be a release without yet more churn in the core system where we could try and stabilize things a bit. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wed, Jan 23, 2013 at 07:59:07PM +, Jaroslav Reznik wrote: The udevd service has a long history of providing predicatable names for block devices and others. For Fedora 19 we'd like to provide the same for network interfaces, following a similar naming scheme, but only as fallback if not other solution such as biosdevname is installed or the administrator manually defined network interface names via udev rules or the old network scripts. [...] This feature is about enabling this as default in Fedora, but only as a fallback if the user/administrator did not manually assign names to interfaces via udev rules, or via the old networking scripts, or if biosdevname is installed. This seems to invent yet another new naming scheme. We just went through this pain, and the biosdevname scheme went through several iterations in the field and represents real-world lessons learned. Is there a compelling reason to make the systemd/udev policy for Fedora not just follow the existing solution to the same problem embodied in biosdevname? (Then, we could just phase out biosdevname.) Also, I strongly question this line in the Feature page: Users generally won't see this, as interface names are not exposed in high-level UIs. This is simply not true for many values of the word user which we support in Fedora, which runs right into the drawback mentioned in the upstream documentation: Does this have any drawbacks? Yes, it does. Previously it was practically guaranteed that hosts equipped with a single ethernet card only had a single eth0 interface. With this new scheme in place, an administrator now has to check first what the local interface name is before he can invoke commands on it where previously he had a good chance that eth0 was the right name. That's pretty big. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 01/23/2013 12:26 PM, Matthew Miller wrote: Also, I strongly question this line in the Feature page: Users generally won't see this, as interface names are not exposed in high-level UIs. This is simply not true for many values of the word user I agree with Matthew that ordinary users do see and use the interface names. The most common usage on my network is ifconfig -a to answer the question, What is (are) my IP address(es) today? Propagation of changes to DNS (multiple competing connections available) takes too long and is unreliable. I further agree that the recent name changes due to biosdevname should be the last for a very long time. That is, anything which might replace biosdevname must produce the same answers as biosdevname. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Matthew Miller (mat...@fedoraproject.org) said: On Wed, Jan 23, 2013 at 07:59:07PM +, Jaroslav Reznik wrote: The udevd service has a long history of providing predicatable names for block devices and others. For Fedora 19 we'd like to provide the same for network interfaces, following a similar naming scheme, but only as fallback if not other solution such as biosdevname is installed or the administrator manually defined network interface names via udev rules or the old network scripts. [...] This feature is about enabling this as default in Fedora, but only as a fallback if the user/administrator did not manually assign names to interfaces via udev rules, or via the old networking scripts, or if biosdevname is installed. This seems to invent yet another new naming scheme. We just went through this pain, and the biosdevname scheme went through several iterations in the field and represents real-world lessons learned. Is there a compelling reason to make the systemd/udev policy for Fedora not just follow the existing solution to the same problem embodied in biosdevname? (Then, we could just phase out biosdevname.) biosdevname naming isn't apparently consistent across versions. https://bugzilla.redhat.com/show_bug.cgi?id=782145#c21 The problems are roughly this: - biosdevname only provides predictable naming for machines with SMBIOS type 9 type 41 records - For other machines, it does 'best effort' based off of heuristics and attempting to enumerate all the devices... which gives weird/unpredictable results. This code has the benefit of: - covering more device types (not just BIOSes with type 9 type 41) - not attempting to do heuristics that name devices via enumeration However, it does have the large disadvantage of changing the namespace used. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 01/23/2013 09:08 PM, John Reiser wrote: On 01/23/2013 12:26 PM, Matthew Miller wrote: Also, I strongly question this line in the Feature page: Users generally won't see this, as interface names are not exposed in high-level UIs. This is simply not true for many values of the word user I agree with Matthew that ordinary users do see and use the interface names. The most common usage on my network is ifconfig -a to answer the question, What is (are) my IP address(es) today? Propagation of changes to DNS (multiple competing connections available) takes too long and is unreliable. I further agree that the recent name changes due to biosdevname should be the last for a very long time. That is, anything which might replace biosdevname must produce the same answers as biosdevname. You do know that biosdevname only works for some hw right? You do realise that this will bring a long history of failures to an end and we finally have something that can work out in a reliable and predictable manner right ? Yes majority of desktop users wont notices this heck they dont even know what ethX or emX is. I for one have had enough of fighting, dealing with the previous mess @dayjob and this actually fixes that and for those admins that want the old ( broken ) behaviour back ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules is all you need. If people want to try this now on F18 they simply can checkout/copy that udev rule /etc/udev/ directory. mailto:mschm...@redhat.com JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wed, Jan 23, 2013 at 10:54 PM, Bill Nottingham nott...@redhat.com wrote: Matthew Miller (mat...@fedoraproject.org) said: On Wed, Jan 23, 2013 at 07:59:07PM +, Jaroslav Reznik wrote: The udevd service has a long history of providing predicatable names for block devices and others. For Fedora 19 we'd like to provide the same for network interfaces, following a similar naming scheme, but only as fallback if not other solution such as biosdevname is installed or the administrator manually defined network interface names via udev rules or the old network scripts. [...] This feature is about enabling this as default in Fedora, but only as a fallback if the user/administrator did not manually assign names to interfaces via udev rules, or via the old networking scripts, or if biosdevname is installed. This seems to invent yet another new naming scheme. We just went through this pain, and the biosdevname scheme went through several iterations in the field and represents real-world lessons learned. Is there a compelling reason to make the systemd/udev policy for Fedora not just follow the existing solution to the same problem embodied in biosdevname? (Then, we could just phase out biosdevname.) biosdevname naming isn't apparently consistent across versions. https://bugzilla.redhat.com/show_bug.cgi?id=782145#c21 The problems are roughly this: - biosdevname only provides predictable naming for machines with SMBIOS type 9 type 41 records - For other machines, it does 'best effort' based off of heuristics and attempting to enumerate all the devices... which gives weird/unpredictable results. This code has the benefit of: - covering more device types (not just BIOSes with type 9 type 41) - not attempting to do heuristics that name devices via enumeration However, it does have the large disadvantage of changing the namespace used. That's certainly right. Here is a bit of the background that lead us here: Udev had the facility to try to keep the ethX names by writing out things to disk from the hotplug path. Looking back at it, it was a big mistake to ever even try this; it created far more problems than it has solved. People with virtualization or random MAC addresses ended up with 1000s of entries, one new for every reboot; in complex setups the renaming of interfaces in the kernel's namespace raced against the kernel creating new interfaces, ending up in device names like rename14, ..., and all these problems. That facility needed to die, that we are absolutely sure about. Now biosdevname was the envisioned future, it provided nice short names, based of static firmware properties or the physical path. So, that was the plan, but as soon as we started looking at the internals, it was not that convincing anymore. Biosdevname initially came up with the physical naming, but to accomplish the goal of nice names it enumerates the entire system and sometimes invents its own pretty numbers based on the *overall* view of the system. A model like that isn't really feasible for upstream udev, udev intentionally wants to be dumb and strictly prefers device-*local* views, and accepts possibly uglier hardware-provided properties, instead of inventing less reliable new pretty numbers. We had no better idea really, than to copy the successful model we do for disks (and other subsystems) with /dev/disk/by-*/ symlinks. It was a well-known scheme, but it was certainly not know for network devices so far. So we picked up the basic ideas from biosdevname and combined them with the proven scheme we do for all other subsystems in udev. This necessarily lead to different names, but from udev's point of view they are entirely justified. We will certainly never win a price for the prettiest names with what we do in udev now, but unlike the earlier solutions, it should be very simple, reliable and predictable. Just looking at 'lspci' will in most cases tell you what the name of the network interface will be. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wed, 23.01.13 15:26, Matthew Miller (mat...@fedoraproject.org) wrote: On Wed, Jan 23, 2013 at 07:59:07PM +, Jaroslav Reznik wrote: The udevd service has a long history of providing predicatable names for block devices and others. For Fedora 19 we'd like to provide the same for network interfaces, following a similar naming scheme, but only as fallback if not other solution such as biosdevname is installed or the administrator manually defined network interface names via udev rules or the old network scripts. [...] This feature is about enabling this as default in Fedora, but only as a fallback if the user/administrator did not manually assign names to interfaces via udev rules, or via the old networking scripts, or if biosdevname is installed. This seems to invent yet another new naming scheme. We just went through this pain, and the biosdevname scheme went through several iterations in the field and represents real-world lessons learned. Is there a compelling reason to make the systemd/udev policy for Fedora not just follow the existing solution to the same problem embodied in biosdevname? (Then, we could just phase out biosdevname.) Yes, because biosdevname bases its names partly on the enumeration order of things, for the sake of pretty names. However, the enumeration order is dependent on system state, and might change when the system changes. i.e. instead of sticking to topology information that is an inherent, stable and fixed property of the devices themselves it invented its own numbering scheme, that is based on properties, configuration and state of the full system. But in order to establish predictable, stable names, regardless in which state your system is, regardless which hardware is currently around, plugged in, probed, and regardless in which order it got added, plugged in and probed, you really don't want to base your naming scheme on the enumeration order, and invent your own naming scheme. The udev naming scheme systemd/udev 197 introduced and which this feature is about only uses physical properties that are local to the devices. That sometimes has the negative effect that the names are not as pretty, but they are guaranteed to be strictly predictable and stable: regardless in which order the kernel probes this hardware, regardless if the user updates the kernel or drivers, or any userspace packages, regardless if the user adds/removes hardware, regardless if the boot is fully parallelized and fast or slow and serialized. That inventing your own numbering is a problem manifests itself in bugs like this: https://bugzilla.redhat.com/show_bug.cgi?id=782145#c21 Also, I strongly question this line in the Feature page: Users generally won't see this, as interface names are not exposed in high-level UIs. This is simply not true for many values of the word user which we support in Fedora, which runs right into the drawback mentioned in the upstream documentation: Well, the page says high-level UIs. The GNOME3 UI certainly doesn't expose the interface name anywhere, does it? But I guess we simply have a different definition of a user here. Your definition is probably closer to what the page calls admins, which is covered by the next lines in the feature page, which you didn't paste: As biosdevname is installed by default ... most administrators won't see this either. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
Hi On Wed, Jan 23, 2013 at 6:28 PM, Lennart Poettering wrote: As biosdevname is installed by default ... most administrators won't see this either. Why doesn;t the proposal request that biosdevname not be installed by default anymore? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wed, 23.01.13 16:54, Bill Nottingham (nott...@redhat.com) wrote: However, it does have the large disadvantage of changing the namespace used. Yes, this is definitely a disadvantage. Which is why we carefully made sure that the new scheme doesn't affect systems which already rely on the stable names, i.e. systems where biosdevname is already installed, or where explicit fixed names have been chosen by the administrator. The new scheme will only take effect if neither biosdevname is installed and no fixed names are assigned by the admin. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 01/23/2013 02:49 PM, Kay Sievers wrote: Just looking at 'lspci' will in most cases tell you what the name of the network interface will be. This is not true for my machines, which I built using main boards from ASUS, MSI, etc. The port numbers listed by 'lspci' (thus part of the default udev name) do NOT correspond to slot numbers in any simple way. Therefore the udev name requires translation in order to find the right cable. This is not good. biosdevname has the advantage that I can determine the mapping between cable and interface name by looking at the back of the machine (where the cables plug in) and counting slots first, then jacks per slot. biosdevname has handled the mapping between physical slot and logical PCI port. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wed, 23.01.13 16:07, John Reiser (jrei...@bitwagon.com) wrote: On 01/23/2013 02:49 PM, Kay Sievers wrote: Just looking at 'lspci' will in most cases tell you what the name of the network interface will be. This is not true for my machines, which I built using main boards from ASUS, MSI, etc. The port numbers listed by 'lspci' (thus part of the default udev name) do NOT correspond to slot numbers in any simple way. Therefore the udev name requires translation in order to find the right cable. This is not good. biosdevname has the advantage that I can determine the mapping between cable and interface name by looking at the back of the machine (where the cables plug in) and counting slots first, then jacks per slot. biosdevname has handled the mapping between physical slot and logical PCI port. I the BIOS provides information about how things are exposed on the backside of the machine, then the new udev native stuff will use that. See the first two naming schemes in the list on: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Jan 24, 2013 at 1:07 AM, John Reiser jrei...@bitwagon.com wrote: On 01/23/2013 02:49 PM, Kay Sievers wrote: Just looking at 'lspci' will in most cases tell you what the name of the network interface will be. This is not true for my machines, which I built using main boards from ASUS, MSI, etc. It certainly is true for every PCI based machine. The default names are strictly what you see in lspci. It's decimal instead of hex, maybe that's what you missed? The port numbers listed by 'lspci' (thus part of the default udev name) do NOT correspond to slot numbers in any simple way. They do, just that they are the PCI geography, not the slot number in the sense of the physical slot number you see printed on your board. What udev does here is the only sensible thing to do, if there is no authoritative information from the firmware about that, we don't make assumptions, we use the reasonable stable PCI geography. Guessing around which might the human slot number should be avoided for many reasons. Therefore the udev name requires translation in order to find the right cable. This is not good. If your firmware supports on-board interfaces, or you use properly firmware-supported PCI hotplug slots, udev names will use exactly these pretty numbers, not the ugly geographical ones. You can even recognize these firmware supported numbers in the udev names, because they use a different prefix. biosdevname has the advantage that I can determine the mapping between cable and interface name by looking at the back of the machine (where the cables plug in) Udev provides exactly the same without the guessing part. If the firmware does not provide authoritative information, udev always uses the geography, which is the safest (granted not the prettiest) thing to do. and counting slots first, then jacks per slot. Anything that *counts* on its own, ever, is doomed to fail in the context of stable name creation. It is in the end not much better than the kernel that just *counted* ethX upwards. The very idea of counting here is the main flaw that lead to the decision that we cannot use the biosdevname scheme in udev. It just cannot work, because you introduce inter-device dependencies, which are not predictable regarding re-configuration. Udev strictly only uses information of the one and single device it handles, never of any of its siblings, because that is where the problem starts, and which cannot be solved in the end. biosdevname has handled the mapping between physical slot and logical PCI port. Sure, and udev does the same, if the firmware supports it. But biosdevname went too far if the firmware lacked the information, and it invented new numbers, based on fragile heuristics and internal counters -- things which we should strictly avoid. Thanks, Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On 01/23/2013 05:29 PM, Kay Sievers wrote: What udev does here is the only sensible thing to do, if there is no authoritative information from the firmware about that, we don't make assumptions, we use the reasonable stable PCI geography. Guessing around which might the human slot number should be avoided for many reasons. FWIW - I did a BIOS upgrade and reconfig on one of our machines and the PCI slot numbers as shown in lscpi changed for our SATA controllers. Caused a bit of panic when we ended up pulling the wrong drive. Perhaps the BIOS assisted names would have been more stable in this case for the ethernet names, I don't know. I'm not trying to disparage this work, it seems reasonable (although I've been bitten by a lot of crappy software assuming network devices are named eth#, but it's able to be turned off, so meh). Just passing along a data point. YMMV and all that. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Jan 24, 2013 at 3:46 AM, Orion Poplawski or...@cora.nwra.com wrote: On 01/23/2013 05:29 PM, Kay Sievers wrote: What udev does here is the only sensible thing to do, if there is no authoritative information from the firmware about that, we don't make assumptions, we use the reasonable stable PCI geography. Guessing around which might the human slot number should be avoided for many reasons. FWIW - I did a BIOS upgrade and reconfig on one of our machines and the PCI slot numbers as shown in lscpi changed for our SATA controllers. Caused a bit of panic when we ended up pulling the wrong drive. Yeah, we see that from time to time, sometimes even just by re-configuring things, not only on firmware upgrades. Perhaps the BIOS assisted names would have been more stable in this case for the ethernet names, I don't know. It should, yes. Firmware provided index/slot/interface numbers seem to work pretty well so far. I'm not trying to disparage this work, it seems reasonable (although I've been bitten by a lot of crappy software assuming network devices are named eth#, but it's able to be turned off, so meh). Right, it's a pain. Some software likes the eth* names to find the MAC address to use that as a machine-id. But all that already happens with biosdevname, and the reported issues seems pretty rare these days. Just passing along a data point. YMMV and all that. Thank you. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
