[JaxCalder]

What

Every mounted file system may bring driver configurations of its own, in <mount point>/cfg/drivers (the layout of the directory dmdevfs is configured from).

• An ioctl on the mount itself. Opening the root of a dmdevfs mount (/dev, not a node in it) gives a handle without a device behind it (a built-in node like /dev/null: EOF on read, writes discarded) that answers DMDEVFS_IOCTL_ADD_CONFIG_DIR and DMDEVFS_IOCTL_REMOVE_CONFIG_DIR (include/dmdevfs.h), argument: the mount point. The command works on the mount that was opened, and only on it. Queued for the hot-plug thread: same procedure as at start (driver_order, dependencies, nodes reported to libsystemd, partitions exposed); removal reports nodes, partitions and hot-plugged devices removed and frees the driver (dmdrvi_free(), module release) after the last open handle. A driver is appended to the mount's list under g_devfs_mutex; configuration file paths may be longer than a node path.

• services/devscan - a one-shot service (like dmdevmon: unit templates + a rule + its own stack):

  devscan add    <dmdevfs path> <mount point>
  devscan remove <dmdevfs path> <mount point>
  

  libsystemd reports every mount as a device of class mount (libsystemd: mounts as devices, a rule key to run a unit on removal, configuration directories of mount points dmsystem#9) and configs/devscan.rules says what to do:

  [class=mount]
  start=devscan@%name              # mounted: configure its cfg/drivers
  remove=devscan-remove@%name      # about to be unmounted: drop them (the unmount waits for it)

  Both units are type=oneshot; nothing stays running. The process runs at priority 3: the unmount waits for the remove unit (up to 20 s) and at priority 0 it did not get the CPU for all of it with the car HMI running. The path of the dmdevfs (/dev) is in the unit file. 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 (libsystemd: mounts as devices, a rule key to run a unit on removal, configuration directories of mount points dmsystem#9).

This replaces the earlier revision of the PR (mountcfg + a public dmdevfs_add_config_dir() that loaded into every dmdevfs mount and called libsystemd, too).

Known limitation

devscan add does not wait for the drivers (the hot-plug thread configures them after it returns).

Testing

• Host: ctest 11/11, incl. test_config_dir (7 steps: arguments, the root handle, configure/remove, only the mount that was asked, once-only loading, driver freed after its last handle, driver goes with its hot-plugged devices).
• STM32F746G-DISCO (dmod-boot#148): devscan runs for every mount and unmount (service list); on a RAM file system with cfg/drivers/dmgpio/x.ini mounted by hand, the node count of /dev goes 63 -> 64 with devscan add and back to 63 when it is unmounted (the rule's remove unit).

Found on the way (not in this PR)

• automount's stack is too small for what a mount report does. dmvfs calls the _mount_changed listeners in the thread that mounts - automount's, 2 kB (2.5 with the overhead). libsystemd loads the configuration directory of the mount point and starts its units there (libsystemd: mounts as devices, a rule key to run a unit on removal, configuration directories of mount points dmsystem#9): 2596 bytes on the board with a card unit and devscan; starting a module from /ext (littlefs) overflowed it: vApplicationStackOverflowHook, the system is dead. automount needs 4 kB (automount: 4 kB of stack and 60 s to stop - what a mount sets going runs in its thread dmblock#6, services/automount/CMakeLists.txt) - tested here that way.
• carhmi does not react to the stop request within its 3 s, so libsystemd kills it - in the middle of a file operation, which leaves the dmvfs mutex locked by a dead thread and freezes every file operation. Unmounting a card with carhmi running hangs the system; carhmi has to stop on request (carhmi-demo).

🤖 Generated with Claude Code

[JohnAmadis]

Pogielo cie? Recznie tworzyc milion procesow i watkow? Po pierwsze to ja nie widze powodu dla ktorego niby potrzebujesz specjalnie uslugi do tego. Po drugie jesli juz to wystarczy jeden watek, po trzecie to przeciez masz obsluge ruli w libsystem - nie widze zadnego powodu aby je tworzyc recznie