From 9fdbf4a44320a8fd82266cc35b6bdc1b006bb38a Mon Sep 17 00:00:00 2001 From: Jax Calder Date: Sun, 25 Oct 2026 19:39:19 +0000 Subject: [PATCH 1/2] devscan: only the drivers are dmdevfs's; units and rules are libsystemd's README and the devscan README now say what a mounted card brings and who loads it: cfg/drivers -> dmdevfs (devscan, ioctl), cfg/services and cfg/rules -> libsystemd, by itself on the mount. Co-Authored-By: Claude Sonnet 5.5 --- README.md | 6 ++++-- services/devscan/README.md | 4 ++++ 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index ac17ef9..98b5df4 100644 --- a/README.md +++ b/README.md @@ -363,10 +363,12 @@ The [devscan](services/devscan/README.md) service makes the calls: libsystemd reports the mounts (dmfsi's `_mount_changed` dif, which dmvfs calls) as devices of class `mount`, a rule starts `devscan add /dev ` for a mount and `devscan remove /dev ` before an unmount, and both end when they -are done. So a mounted card or `/ext` just brings its drivers: +are done. So a mounted card or `/ext` just brings its configuration: ``` -/cfg/drivers/ driver configurations -> dmdevfs +/cfg/drivers/ driver configurations -> dmdevfs (devscan) +/cfg/services/ units -> libsystemd (by itself, on the mount) +/cfg/rules/ device rules -> libsystemd (by itself, on the mount) ``` - **mounted** - the drivers are configured by the hot-plug thread. A mount diff --git a/services/devscan/README.md b/services/devscan/README.md index 6885d59..89f3404 100644 --- a/services/devscan/README.md +++ b/services/devscan/README.md @@ -16,6 +16,10 @@ and does an ioctl on it - `DMDEVFS_IOCTL_ADD_CONFIG_DIR` / [`include/dmdevfs.h`](../../include/dmdevfs.h) - then ends. dmdevfs queues the work for its hot-plug thread. A mount point without `cfg/drivers` is left alone. +Only the drivers are dmdevfs's: the units and rules of a mount point +(`cfg/services`, `cfg/rules`) are loaded by libsystemd itself when the file +system is mounted. + ## How it is started Nothing here follows mounts. libsystemd reports every mount as a device of class From f1f62246af150441c9950d9492257fa8a25929d7 Mon Sep 17 00:00:00 2001 From: Jax Calder Date: Sun, 25 Oct 2026 23:14:25 +0000 Subject: [PATCH 2/2] devscan: priority 3 - the unmount waits for its remove unit A mount's `remove` unit is waited for by the unmount (up to 20 s). At priority 0 a process gets the CPU only in the gaps, and with the car HMI running (a decoder at 2, a view at 1) devscan-remove did not get through for the whole 20 s. It does a few file operations and ends, so it runs above them. Co-Authored-By: Claude Sonnet 5.5 --- services/devscan/CMakeLists.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/services/devscan/CMakeLists.txt b/services/devscan/CMakeLists.txt index b3beadb..15e5c37 100644 --- a/services/devscan/CMakeLists.txt +++ b/services/devscan/CMakeLists.txt @@ -9,7 +9,10 @@ set(DMOD_AUTHOR_NAME "Patryk Kubiak") # Its own stack: it only opens a file and calls an ioctl, but the thread that mounts (automount's) is far too small # to do even that inline set(DMOD_STACK_SIZE 2048) -set(DMOD_PRIORITY 0) +# Above the services (0): a mount's `remove` unit is waited for by the unmount, and on a busy system (the car HMI) a +# priority-0 process gets the CPU only in the gaps - it took the 20 s the unmount waits for it at most. It does +# a few file operations and ends. +set(DMOD_PRIORITY 3) set(DMOD_DMR_PATH ${CMAKE_CURRENT_SOURCE_DIR}/devscan.dmr) dmod_add_executable(${DMOD_MODULE_NAME} ${DMOD_MODULE_VERSION}