This commit add the `-i` option to `udevadm trigger` that force it to
match parent devices even if they're excluded from filters.
The rationale is that some embedded devices have a huge number of
platform devices ( ~ 4k for MX8 ) they are there because they're defined
in the device tree but there isn't any action or udev rules associated
with them.
So at boot a significant time is spend triggering and processing rules
for devices that don't produce any effect and we would like to filter
them by calling:
```
udevadm trigger --type=device --action=add -s block -s tty
```
instead of the normal
```
udevadm trigger --type=device --action=add
```
so we can use filter to filter out only subsystems for we we know that
we have rules in place that do something useful.
On the other side action / rules are not triggered until the parent is
triggered ( which is part of another subsystem), so the additional option
will allows udev to complete the coldplug with only the devices we care.
Example on iMX8:
.Without the new option
```
root@dev:~# udevadm trigger --dry-run -s block --action=add -v
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0boot0
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0boot1
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p1
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p2
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p3
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p4
```
.With the new option
```
root@dev:~# udevadm trigger --dry-run -i -s block --action=add -v
/sys/devices/platform
/sys/devices/platform/bus@5b000000
/sys/devices/platform/bus@5b000000/5b010000.mmc
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0boot0
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0boot1
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p1
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p2
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p3
/sys/devices/platform/bus@5b000000/5b010000.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p4
```
Boot time reduction with this is place is ~ 1 second.
This function was listed in the public sd-varlink.h header, but not
actually made public. Fix that. It's quite useful, the comment in it
describes the usecase nicely.
Fixes: #35554
Fixes https://github.com/systemd/systemd/issues/35508.
As reported in the bug, the values were hardcoded for the systemd project.
https://varlink.org/Service lists vendor, product, version, url, and interfaces
as the mandatory parameters, so add an interface to set the first four. The
last field is set automatically based on the registered interfaces as before.
If the values are not filled in, we return empty strings. With NULL,
'varlinkctl info' would say:
(string):1:25: Object field 'vendor' has wrong type null, expected string.
The calls are now unused, and we generally prefer if people send a PID
triplet rather than a single PID, hence stop supporting a high-level
dispacher for pid_t.
Follow-up for bab889c51e (#33032).
Currently, they unconditionally returns EPOLLIN and USEC_INFINITY, respectively.
Just for consistency with sd-bus, sd-journal, sd-varlink, and so on. All
they have _get_fd(), _get_events(), and _get_timeout().
Closes#34094.
To create the sd_device object of a driver, the function
sd_device_new_from_subsystem_sysname() requires "drivers" for subsystem
and e.g. "pci:iwlwifi" for sysname. Similarly, sd_device_new_from_device_id()
also requires driver subsystem. However, we have never provided a
way to get the driver subsystem ("pci" for the previous example) from
an existing sd_device object.
Let's introduce a way to get driver subsystem.
To make it work without sd-event.
Prompted by recent chat:
> Hey all!
> reading man libudev, it says to use sd-device instead now. I've read that
> APIs header file and it seems it no longer has an equivalent to libudev's
> udev_monitor_get_fd, which AFAICT means I have to use sd-event to watch
> for events I'm interested in. I know I can "embed" sd-event in other event
> loops I might already have, but that seems overkill when I'm only interested
> in this one type of event and don't need sd-event for anything else.
It's time. sd-json was already done earlier in this cycle, let's now
make sd-varlink public too.
This is mostly just a search/replace job of epical proportions.
I left some functions internal (mostly IDL handling), and I turned some
static inline calls into regular calls.
This is preparation for making our Varlink API a public API. Since our
Varlink API is built on top of our JSON API we need to make that public
first (it's a nice API, but JSON APIs there are already enough, this is
purely about the Varlink angle).
I made most of the json.h APIs public, and just placed them in
sd-json.h. Sometimes I wasn't so sure however, since the underlying data
structures would have to be made public too. If in doubt I didn#t risk
it, and moved the relevant API to src/libsystemd/sd-json/json-util.h
instead (without any sd_* symbol prefixes).
This is mostly a giant search/replace patch.
Let's support enumerating over devices that match all of the given
properties instead of any of the given properties by adding a new
function sd_device_enumerator_add_match_property_required() which
specifies properties that should all be matched instead of just one.
Fixes#28372
We exported sd_id128_get_machine_app_specific() and
sd_id128_get_boot_app_specific(). But those operate on the current machine,
and sometimes the user might want to do the same calculation for a different
machine, or an earlier boot, etc. We expose the underlying implementation
to make this easy.
After the commit 7a4ee86161,
sd_journal_next() following sd_journal_seek_tail() takes no-op,
and we need to call sd_journal_previous(). This may be useful in
some cases, e.g. to fix the issue explained in the previous commit.
I guess it was only a question of time until we need to add the final
frontier of notification functions: one that combines the features of
all the others:
1. specifiying a source PID
2. taking a list of fds to send along
3. accepting a format string for the status string
Hence, let's add it.
This is a follow-up for b1712fabd1 which
was prepped for 253, but merged into early 254 development cycle. It
thus had the symbol it adds at the wrong symver. Fix thta.
Same as the sd_pid_* counterparts, but take a pid file descriptor instead of
a pid, so that the callers can be sure that the returned values are really
about the process they asked for, and not about a recycled PID.
In many (most?) of our event loops we want to exit once SIGTERM/SIGINT
is seen. Add a common helper for that, that does the right things in a
single call.
This effectively reverts 84e1001541.
The sd-netlink library has several issues, and we should not export it
without solving them. See issues #24258 and #24124.
Lennart Poettering
Thorsten Kukuk
Federico Giovanardi
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Mike YuanandThorsten Kukuk
Ivan Kruglov
Daan De Meyer
Luca Boccassi
Erik Moqvist