0 can be a valid index returned by the BIOS, so allow that by using the
parsing function safe_atolu() to check for errors without excluding the
valid value "0".
Signed-off-by: Joe Hershberger <joe.hershberger@ni.com>
We use strtoul() which returns an "unsigned long", but then assign this
to int or unsigned in, i.e. drop 32bit silently on 64bit systems. Let's
clean this up a bit, and retain the right types.
In older kernels IPoIB network devices expose the port number via
the sysfs attribute 'dev_id', which is not intended to be used this way.
Let's support both options for a while.
An InfiniBand network address is 20 bytes long. Only the least
significant 8 bytes can be interpreted as a persistent hardware unit
identifier; the other 12 are transiently derived at runtime from metadata
specific to the protocol stack.
However, since the network interface name length is hard-capped by
IFNAMSIZ at 16 chars and the 2-byte type prefix with '\0' at the end
leave us only at 13, we cannot squeeze a descriptive representation of a
HW address into an interface name. Thus, it makes the most sense to drop
the scheme for IPoIB interfaces entirely.
Currently udev just gets confused and does what it has been taught
to do: fetches the first six bytes and puts them into a permanent
device attribute.
We've long neglected IP-over-InfiniBand network interfaces, let's treat
them the same way we treat anyone else.
IPoIB interfaces will retain the 'ib' prefix; otherwise the naming scheme
is the same one we use for other network interfaces. E.g. a IPoIB network
device provided by a PCI card at bus 21 slot 0 function 6 will be named
'ibp21s0f6'.
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
This drops a good number of type-specific _cleanup_ macros, and patches
all users to just use the generic ones.
In most recent code we abstained from defining type-specific macros, and
this basically removes all those added already, with the exception of
the really low-level ones.
Having explicit macros for this is not too useful, as the expression
without the extra macro is generally just 2ch wider. We should generally
emphesize generic code, unless there are really good reasons for
specific code, hence let's follow this in this case too.
Note that _cleanup_free_ and similar really low-level, libc'ish, Linux
API'ish macros continue to be defined, only the really high-level OO
ones are dropped. From now on this should really be the rule: for really
low-level stuff, such as memory allocation, fd handling and so one, go
ahead and define explicit per-type macros, but for high-level, specific
program code, just use the generic _cleanup_() macro directly, in order
to keep things simple and as readable as possible for the uninitiated.
Note that before this patch some of the APIs (notable libudev ones) were
already used with the high-level macros at some places and with the
generic _cleanup_ macro at others. With this patch we hence unify on the
latter.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
NPAR is a technology that allows a single network interface to
be divided into number of partitions. The partitions show up
as functions on the same PCI device... when there are more than
8 functions, ARI (alternative routing-ID interpretation) is
used. With ARI is enabled, the 8 bit field that normally has 5
bits for the PCI device and 3 bits for the PCI function is instead
interpreted as (implicit) device 0, with 8 bits for the function
number.
Because the linux kernel exposes the PCI device/function numbers
to userspace the same regardless of whether ARI is enabled,
systemd predictable device naming can generate unpredictable
names in this case, because network names using the PCI slot use
the function number, but not the device number, causing systemd
to generate the same name for mulitple network devices (so some
will revert to the "ethX" names).
With this patch, device naming code checks if ARI is enabled for
a PCI network device, and uses the full 8-bit function number
for naming to avoid this situation. This should improve
readability and predictability of device names.
Here is an example of how this change would affect naming:
before patch | after patch
-----------------------------
ens2f0 | ens2f0 NPAR partition 0 (in PCI slot 2)
ens2f1 | ens2f1 NPAR partition 1
...
ens2f7 | ens2f7 NPAR partition 7
eth1 | ens2f8 NPAR partition 8
eth2 | ens2f9 NPAR partition 9
With PCI SR-IOV, a number of virtual network devices can be enabled,
all of which share the same physical network device. Currently,
udev generates names for SR-IOV virtual functions as if they were
independent network devices.
With this change, the predictable network device naming code will
check if a network device is an SR-IOV virtual device, and will
generate a name based on the physical PCI device plus a "v%u"
suffix. This should improve readability and predictability of
device names.
Here is an example of how this change would affect naming:
before patch | after patch
-----------------------------
eno1 | eno1 onboard NIC, physical function
enp101s0f0 | eno1v0 onboard NIC, SR-IOV virtual func 0
enp101s0f1 | eno1v1 onboard NIC, SR-IOV virtual func 1
To generate predictable network device names, the code in
udev-builting-net_id.c tries to match the PCI device address
of the network device to the entries in /sys/bus/pci/slots.
However, sometimes the slot number is not associated the
network controller PCI device itself, but rather with one of
its parents.
This change will try to find a match in /sys/bus/pci/slots for
the parents of the PCI network device, if it doesn't find a
match for the device itself.
This was a bug inadvertently added by commit 73fc96c8ac.
The intent of the check is to "match slot address with device by
stripping the function" (as the comment above states it), for example
match network device PCI address 0000:05:00.0 (including a .0 for
function) to PCI slot address 0000:05:00, but changing that to a streq()
call prevented the match.
Change that to startswith(), which should both fix the bug and make the
intent of the check more clear and prevent unintentional bugs from being
introduced by future refactorings.
gcc-8 throws an error if it knows snprintf might truncate output and the
return value is ignored:
../src/udev/udev-builtin-net_id.c: In function 'dev_pci_slot':
../src/udev/udev-builtin-net_id.c:297:47: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size between 0 and 4095 [-Werror=format-truncation=]
snprintf(str, sizeof str, "%s/%s/address", slots, dent->d_name);
^~
../src/udev/udev-builtin-net_id.c:297:17: note: 'snprintf' output between 10 and 4360 bytes into a destination of size 4096
snprintf(str, sizeof str, "%s/%s/address", slots, dent->d_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
Let's check all return values. This actually makes the code better, because there's
no point in trying to open a file when the name has been truncated, etc.
c20e6de897 introduced a format string as
variable, but didn't turn off -Wformat-nonliteral warnings on it, thus
breaking the build. Let's fix that, by simply turning off the warning in
this case, as we know it's safe.
For IBM PowerVM Virtual I/O network devices, we can build predictable names
based on the slot number passed as part of the OF "reg" property. Valid slot
numbers range between 2-32767, so we only need the bottom half of the unit
address passed.
For example:
/proc/device-tree/vdevice/l-lan@30000002
/proc/device-tree/vdevice/vnic@30000005
would initially map to something like:
/sys/devices/vio/30000002/net/eth0
/sys/devices/vio/30000005/net/eth1
and would then translate to env2 and env5
This patch ignores the bus number, as there should only ever be one bus, and
then remove leading zeros.
The CCW id_net_name_path detection didn't account for virtio
interfaces on the CCW bus. As a result the default interface
names for virtio-ccw interfaces would use the old eth<x>
format instead of enc<busid>.
Since virtio-pci interface naming follows the naming rules
of the parent bus, the names_ccw() logic was changed to apply
the CCW interface naming rules to virtio interfaces as well,
e.g. enc2000 for an interface with a CCW bus id 0.0.2000.
As virtio interfaces are apt to get the otherwise unusual
CCW bus id 0.0.0000, the last '0' is now preserved in this
case.
The virtio subsystem skipping loop has been moved from
names_pci() into a function skip_virtio() that can be reused
for all bus types with virtio network devices.
Since virtio-ccw interfaces use single CCW addresses the ccwgroup
requirement was relaxed and the C definitions were changed
accordingly.
This reverts some changes introduced in d054f0a4d4.
xsprintf should be used in cases where we calculated the right buffer
size by hand (using DECIMAL_STRING_MAX and such), and never in cases where
we are printing externally specified strings of arbitrary length.
Fixes#4534.
Switch drivers uses phys_port_name attribute to pass front panel port
name to user. Use it to generate netdev names.
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
The commmon case default qeth link is enccw0.0.0600 is rather long.
Thus strip leading zeros (which doesn't make the bus_id unstable),
similar to the PCI domain case.
Also 'ccw' is redundant on S/390, as there aren't really other buses
available which could have qeth driver interfaces. Not sure why this
code is even compiled on non-s390[x] platforms. But to distinguish from
e.g. MAC stable names shorten the suffix to just 'c'.
Thus enccw0.0.0600 becomes enc600.
