[JaxCalder]

What

libsystemd hears every mount and unmount (dmfsi's _mount_changed dif, called by dmvfs) and uses it for three things:

• The mount is a device of class mount - named after the mount point (/mnt/SD -> mnt_SD, /ext -> ext, / -> root), the mount point as its value (%v). The rules decide what that means, and whatever they start does its work in a process of its own, with the stack its module asks for.
• Rules: a new remove key. A section may have start, remove or both; remove is a unit started when a device of the class goes away (after the units start started are stopped), with %name and the value the device was reported with as %v. The removal waits for it (up to 20 s each) - an unmount must not go on before the units of the file system are done.
• The configuration directory of the mount point, loaded by libsystemd itself - no API for anyone to call. <mount point>/cfg/services and cfg/rules are added to what libsystemd_scan() / libsystemd_load_rules() loaded (nothing is reloaded or restarted) when a file system is mounted, and its units start in their dependency order; before the unmount the remove units run, then everything that came from there stops and is dropped (template instances included). A full reload keeps the loaded directories, the units directory of libsystemd_scan() is never loaded twice, a unit or template whose name is taken stays the first one. %m = the mount point the unit comes from, e.g. exec=%m/bin/app.dmfc, so a unit stays bound to its own card. The module search path is invalidated first - /mnt/<label>/bin is on it, cached, and automount only gets to it after the mount returned.
• Registry lock: libsystemd is called from several threads (dmdevfs hot-plug, the shell, systemd) - two of them starting the same template instance registered it twice on the board. A recursive lock guards the lists only and is never held while a unit is spawned, stopped or waited for. libsystemd_forget_device() leaked the device's user value.

The drivers of a mount point (cfg/drivers) are not libsystemd's: dmdevfs loads them, asked to by a service a rule starts (devscan, choco-technologies/dmdevfs#75).

Stack

The dif is called in the thread that mounts - automount's. Loading a directory and starting a unit from a card there peaked at 2596 bytes of automount's stack on the board (a card unit, carhmi, plus the one-shot devscan); automount is released with 2 kB (2560 with the overhead), so it needs 4 kB (choco-technologies/dmblock#6, services/automount/CMakeLists.txt) - without it the stack overflows (vApplicationStackOverflowHook).

Testing

• Host: test_libsystemd 73/73 (10 new: the dif is implemented, a mount is a device the start rule matches with the mount point as %v, an unmount starts the remove unit with the remembered value, a rule with only remove; a mount adds/starts and an unmount removes the units of cfg/services, the first definition stays, rules and templates of a mount point, survival of a full reload, no double loading of the scanned directory, a mount without cfg/), test_systemd / test_service 1/1. The host loader needs Dmod_InvalidateModuleSearchPaths (dmod develop).
• STM32F746G-DISCO with dmod-boot#148: after a cold boot the card is mounted, carhmi starts from <card>/cfg/services/carhmi/carhmi.ini by itself and devscan runs; a probe unit in /ext/cfg/services: umount /ext + mount loads it (fresh instance each cycle, %m = /ext, exactly one), devscan-remove@ext runs on every unmount.

Needs dmfsi with the _mount_changed dif (choco-technologies/dmfsi#21, merged). Part of: choco-technologies/dmdevfs#75, choco-technologies/dmod-boot#148.

🤖 Generated with Claude Code