| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
To support predictable interface names in various embeeded systems
add support for an additional naming scheming using the USB host
interface. Several asics have usb controllers that are platform
devices and not children of a pci interface. These embedded systems
should be able to enumerate interfaces by udev path as well to support
configurations and policies.
Signed-off-by: Charles Hardin <charles.hardin@chargepoint.com>
|
| |
|
|
|
|
| |
I noticed a typo in the man page. Fix it.
Fixes: 65c2ad985a ("udev: net_id: Use devicetree aliases when available")
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Devicetree firmware contains an "aliases" node, containing various
aliases for devices described by the firmware. For ethernet devices,
these are named "ethernet0", "ethernet1", etc. They provide a convenient
means of numbering ethernet devices, especially on systems with no other
stable number other than the address. In particular, U-Boot already uses
these aliases to name its ethernet devices.
Previously, there have been attempts (such as [1]) to add support for
these aliases to Linux. However, these patches have been rejected
because it is the maintainers' view that naming policy be left to
userspace. Well, systemd is userspace, so here we are.
In terms of implementation, apparently there can be multiple device
trees at once. I have decided to dodge this problem for now, and just
use /proc/device-tree. If it is desired to support multiple device trees
later, then the scheme can be modified to include the device tree's
index. For example, /sys/firmware/devicetree/base2/aliases/ethernet3
might be named enb2d3.
For the moment we only support "ethernetX" aliases. Future patches might
want to also handle "canX" and "wifiX".
It is common on boards with only one ethernet device to use an alias of
just "ethernet". In this case, the index is an implicit 0. In case the
author of the firmware made a mistake, we check to ensure that aliases
of "ethernet" and "ethernet0" do not both exist.
[1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/1399390594-1409-1-git-send-email-boris.brezillon@free-electrons.com/
Closes: #17625
|
| |
|
|
|
|
|
| |
If we have two or more devices that share the same slot but they are
also multifunction then it is OK to use the slot information even if it
is the same for all of them. Name conflict will be avoided because we
will append function number and form names like, ens1f1, ens1f2...
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Those devices show up as /sys/devices/vif-N, let's use that number
to name them enXN.
Without this, all schemes fail and they keep the kernel names, which can
be racy.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
|
| |
|
|
|
| |
Follow-up for b4d885f0e861b2d1bb5a62311c61a96f5222b026 and
068b0f77289411ef9f92f5d701759e98145a06e4.
|
| |
|
|
|
|
|
|
|
|
| |
The maximum allowed value of the sysfs device index entry was limited to
16383 (2^14-1) to avoid the generation of unreasonable onboard interface
names.
For s390 the index can assume a value of up to 65535 (2^16-1) which is
now allowed depending on the new naming flag NAMING_16BIT_INDEX.
Larger index values are considered unreasonable and remain to be
ignored.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The s390 PCI driver assigns the hotplug slot name from the
function_id attribute of the PCI device using a 8 char hexadecimal
format to match the underlying firmware/hypervisor notation.
Further, there's always a one-to-one mapping between a PCI
function and a hotplug slot, as individual functions can
hot plugged even for multi-function devices.
As the generic matching code will always try to parse the slot
name in /sys/bus/pci/slots as a positive decimal number, either
a wrong value might be produced for ID_NET_NAME_SLOT if
the slot name consists of decimal numbers only, or none at all
if a character in the range from 'a' to 'f' is encountered.
Additionally, the generic code assumes that two interfaces
share a hotplug slot, if they differ only in the function part
of the PCI address. E.g., for an interface with the PCI address
dddd:bb:aa.f, it will match the device to the first slot with
an address dddd:bb:aa. As more than one slot may have this address
for the s390 PCI driver, the wrong slot may be selected.
To resolve this we're adding a new naming schema version with the
flag NAMING_SLOT_FUNCTION_ID, which enables the correct matching
of hotplug slots if the device has an attribute named function_id.
The ID_NET_NAME_SLOT property will only be produced if there's
a file /sys/bus/pci/slots/<slotname> where <slotname> matches
the value of /sys/bus/pci/devices/.../function_id in 8 char
hex notation.
Fixes #19016
See also #19078
|
| |
|
|
| |
Fixes #18397.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
v246 is long released. Hence the new scheme should be named v247.
(Interesting, how we pretty systematically for the last releases changed
the scheme only every second release)
|
| |
|
|
| |
the same slot
|
| |
|
|
| |
Fixes #16363. Also includes some changes where I generalized the pattern.
|
| | |
|
| |
|
|
| |
We generate "v" in two different ways, and they got mixed up.
|
| |
|
|
| |
and ID_NET_LABEL_ONBOARD
|
| |
|
|
|
|
|
|
| |
This commit lowers the chance of having veth name conflicts for machines
created with similar names.
Replaces: #12865
Fixes: #13417
|
| |
|
|
|
|
| |
The document was imported back in
f9e6d49904e06d2cba3871f6873d0519fe086d0f. Let's make sure we actually
point to that version rather than the old one on freedesktop.
|
| | |
|
| |
|
|
| |
We nowadays prefer positive options over negative.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
s/and and/and/
s/explicity/explicitly/
s/that that/that/
s/the the/the/
s/is is/it is/
s/overriden/overridden/
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is for 6d3646406560. It turns out that this is causing more problems than
expected. Let's retroactively introduce naming scheme v241 to conditionalize
this change.
Follow-up for #12792 and 6d36464065601f7. See also
https://bugzilla.suse.com/show_bug.cgi?id=1136600.
$ SYSTEMD_LOG_LEVEL=debug NET_NAMING_SCHEME=v240 build/udevadm test-builtin net_setup_link /sys/class/net/br11
$ SYSTEMD_LOG_LEVEL=debug NET_NAMING_SCHEME=v241 build/udevadm test-builtin net_setup_link /sys/class/net/br11
...
@@ -20,11 +20,13 @@
link_config: could not set ethtool features for br11
Could not set offload features of br11: Operation not permitted
br11: Device has name_assign_type=3
-Using interface naming scheme 'v240'.
+Using interface naming scheme 'v241'.
br11: Policy *keep*: keeping existing userspace name
br11: Device has addr_assign_type=1
-br11: No stable identifying information found
-br11: Could not generate persistent MAC: No data available
+br11: Using "br11" as stable identifying information
+br11: Using generated persistent MAC address
+Could not set Alias=, MACAddress= or MTU= on br11: Operation not permitted
+br11: Could not apply link config, ignoring: Operation not permitted
Unload module index
Unloaded link configuration context.
ID_NET_DRIVER=bridge
|
| |
|
|
|
|
| |
This is in preparation for later changes. Let's change the documentation of
net.naming-scheme= to also say that it applies to MAC addresses. This commit
doesn't actually implement that though.
|
| |
|
|
|
|
|
| |
The comment in udev-builtin-net_id.c (removed in grandparent commit) showed the
property without the prefix. I assume that was always the intent, because it
doesn't make much sense to concatenate anything to an arbitrary user-specified
field.
|
|
|
I decided to make this a separate man page because it is freakin' long.
This content could equally well go in systemd-udevd.service(8), systemd.link(5),
or a new man page for the net_id builtin.
v2:
- rename to systemd.net-naming-scheme
- add udevadm test-builtin net_id example
|
