[JaxCalder]

Problem

carhmi (moved to the SD card in #145/#147) never started: its unit was in the firmware's /configs, started at boot before automount had mounted the card, and libsystemd skips a unit whose module it cannot find.

Change

• The config filesystem is mounted at /cfg (systemd gets /cfg/services /cfg/rules, dmdevfs /cfg/drivers); a build directory that still holds the old defaults in its cache is switched over.
• Configuration goes where the module goes: the service=, rules=, driver= files of the sdcard and ext modules go to build/sdcard/cfg and build/ext/cfg (= <card>/cfg, /ext/cfg) instead of the firmware; upload-files / upload-ext send them with the modules.
• libsystemd loads <mount point>/cfg/services and cfg/rules by itself when a file system is mounted (it implements dmfsi's _mount_changed dif, called by dmvfs) and drops them before the unmount. %m in such a unit is the mount point, so it stays bound to its own card. The unit of the car HMI demo is the one it ships (carhmi.ini, now on the card).
• devscan: the same mount is a device of class mount; devscan.rules starts the one-shot devscan service (dmdevfs) for it - add when it is mounted, remove before it is unmounted (the unmount waits for it); it asks dmdevfs, by an ioctl on /dev, to configure / drop <mount point>/cfg/drivers, and ends.
• lib/dmvfs -> develop (mount reports through dmfsi's dif).
• docs and tests/test_module_layout.py updated (passes).

Dependencies - do not merge before

• libsystemd: mounts as devices, a rule key to run a unit on removal, configuration directories of mount points dmsystem#9 and devscan: driver configuration directories of mount points, by ioctl on the mount dmdevfs#75 are merged, but not released, and each lacks its last commits: libsystemd: load the configuration directory of a mount point by itself (follow-up to #9) dmsystem#10 (libsystemd loads a mount point's cfg/services and cfg/rules by itself) and devscan: priority 3; docs - units and rules are libsystemd's (follow-up to #75) dmdevfs#77 (devscan priority). Until they are released the build needs local packages (-DDMBOOT_MANIFEST_URL=<local manifest>); I tested that way.
• automount with a 4 kB stack and 60 s to stop (automount: 4 kB of stack and 60 s to stop - what a mount sets going runs in its thread dmblock#6, the repo formerly dmblkid): the mount's units start and stop in its thread - 2596 bytes of stack with carhmi, and an unmount that waits for the units.
• port: recover a controller left with a transfer; waits bounded by time dmqspi#4 (/ext stayed dead ~1 min after boot with carhmi running) and Stop on request in 3.7 s instead of 5+: stop all threads at once; the unit waits 15 s carhmi-demo#15 (merged).
• Already merged: dmvfs#63, Dodać możliwość podania ścieżki do paczki release'owej modułu głównego #64, Add DMBOOT_MAIN_MODULE_PACKAGES_DIR for local module installation #65, Dodać flagę DMBOOT_MANIFEST_URL #66 (the submodule pointer is dmvfs develop) and dmfsi#21 (the _mount_changed dif).

Testing (STM32F746G-DISCO, real board)

• The firmware builds and flashes; after a cold boot the card is mounted by automount, devscan runs for every mount, and carhmi starts by itself from the unit on the card (service list: running).
• A probe unit in /ext/cfg/services: umount /ext + mount loads it (%m = /ext), once per cycle with a fresh instance, devscan-remove@ext / devscan@ext run every time.
• A RAM file system mounted by hand with cfg/drivers/dmgpio/x.ini: devscan add /dev /rt adds the node (63 -> 64), umount /rt runs the remove units and the node is gone (63).

Known problems (not in this PR)

• carhmi stops too slowly (5+ s, libsystemd kills it after 3 s, in the middle of a file operation, which leaves the dmvfs mutex locked by a dead thread). Fixed in Stop on request in 3.7 s instead of 5+: stop all threads at once; the unit waits 15 s carhmi-demo#15 (stops all its threads at once, stop_timeout_ms=15000 in its unit: 5.4 s -> 3.7 s, and the stop is waited for, not killed). With it, dmblock#6 (60 s for automount's stop) and devscan at priority 3, unmounting the card with the HMI running completes (25 s on the board) instead of hanging.
• dmqspi under load: with carhmi running, /ext reads started failing (EIO/EBUSY) ~1 min after boot, until reset - QUADSPI is left with an indirect read stalled on a full FIFO and the driver never aborted it. Fixed in port: recover a controller left with a transfer; waits bounded by time dmqspi#4 (the firmware tested here carries it: 500+ commands from /ext in a row over 9 minutes, none failed).

🤖 Generated with Claude Code