This is preparation for #28891, which adds a bunch more helpers around
"struct iovec", at which point this really deserves its own .c/.h file.
The idea is that we sooner or later can consider "struct iovec" as an
entirely generic mechanism to reference some binary blob, and is the
go-to type for this purpose whenever we need one.
This allows distros to install configuration file templates in /usr/lib/systemd
for example.
Currently we install "empty" config files in /etc/systemd/. They serve two
purposes:
- The file contains commented-out values that show the default settings.
- It is easier to edit the right file if it is already there, the user doesn't
have to type in the path correctly, and the basic file structure is already in
place so it's easier to edit.
Things that have happened since this approach was put in place:
- We started supporting drop-ins for config files, and drop-ins are the
recommended way to create local configuration overrides.
- We have systemd-analyze cat-config which takes care of iterating over
all possible locations (/etc, /run, /usr, /usr/local) and figuring out
the right file.
- Because of the first two points, systemd-analyze cat-config is much better,
because it takes care of finding all the drop-ins and figuring out the
precedence. Looking at files manually is still possible of course, but not
very convenient.
The disadvantages of the current approach with "empty" files in /etc:
- We clutter up /etc so it's harder to see what the local configuration actually is.
- If a user edits the file, package updates will not override the file (e.g.
systemd.rpm uses %config(noreplace). This means that the "documented defaults"
will become stale over time, if the user ever edits the main config file.
Thus, I think that it's reasonable to:
- Install the main config file to /usr/lib so that it serves as reference for
syntax and option names and default values and is properly updated on package
upgrades.
- Recommend to users to always use drop-ins for configuration and
systemd-analyze cat-config to view the documentation.
This setting makes this change opt-in.
Fixes#18420.
[zjs: add more text to the description]
Let's support the same filtering options that we also support in
udevadm trigger in udevadm info to filter the devices produced by
--export-db.
One difference is that all properties specified by --propery-match=
have to be satisfied in udevadm info unlike udevadm trigger where just
one of them has to be satisfied.
systemd's own cgroup hierarchy is special to us, we use it to actually
manage processes. Because of that many calls tha apply to cgroups are
only ever called with the SYSTEMD_CGROUP_CONTROLLER as controller
argument. Let's hence remove the argument altogether.
This in particular touches the kill and xattr routines.
This changes no behaviour, we just drop an argument that is always set
to the same value anyway.
This is preparation to eventually getting rid of the cgroupvs1, because
on cgroupvs2 the cgroup paths do not change for different controllers,
there's only a single hierarchy there.
We might need a lot of fds on large systems, hence raise RLIMIT_NOFILE
to what the service manager allows us, which is quite a lot these days.
udev already sets FORK_RLIMIT_NOFILE_SAFE when forking of chilren, thus
ensuring that forked off processes get their RLIMIT_NOFILE soft limit
reset to 1K for compat with crappy old select().
Replaces: #29298Fixes: #28583
path_simplify_full()/path_simplify() are changed to allow a NULL path, for
which a NULL is returned. Generally, callers have already asserted before that
the argument is nonnull. This way path_simplify_full()/path_simplify() and
path_simplify_alloc() behave consistently.
In sd-device.c, logging in device_set_syspath() is intentionally dropped: other
branches don't log.
In mount-tool.c, logging in parse_argv() is changed to log the user-specified
value, not the simplified string. In an error message, we should show the
actual argument we got, not some transformed version.
This partially revert 0454cf05d3.
The executable actually does not work with itself, but needs to be
combined with test-udev.py. But, even so, the executable is for testing.
In the next commit, test and normal executables are declared in the same
way, and naming of the executable becomes essential to classify them.
Let's rename the executable and prefix with 'test-'.
Previously, we first generate names based on the PCI slot and ACPI
onboard index, and then append an identifier based on USB or BCMA bus
if it exists in between the PCI bus and the interface.
However, if there exists USB or BCMA bus, the name based on the
ACPI onboard index is not used.
So, let's invert the order; first generate USB or BCMA identifier if the
bus exists, then prepend the name with the PCI slot identifier.
With this change, we can drop Names struct, and each naming logic
becomes self-consistent.
Then call it only when it is necessary. The label is used only when the
interface is directly connected to the PCI bus, and it does not have the
SR-IOV feature (or the naming based on SR-IOV is disabled).
This contains redundant copy of BCMA identifier, but that will be
dropped in the next commit.
No functional change, just refactoring and preparation for later
commits.
This contains redundant copy of USB identifier, but that will be
dropped in the next commit.
No functional change, just refactoring and preparation for later
commits.
This also changes the onboard index type to unsigned, as it is at most
2^16 - 1. Hence, unsigned is enough.
Then, we can use device_get_sysattr_unsigned() helper function.
This also drops mostly redundant debugging logs. The index will be
logged later anyway.
As dev_port and dev_id sysfs attributes are fundamental properties for
network interfaces. Hence, it should not fail.
Also, the type of dev_port is changed to unsigned. The kernel internally
uses 'unsigned short' for dev_port and dev_id. Hence, unsigned (that is,
32 bits) is still overkill, but should be enough.