So, no SysV /etc/init.d because no shell scripting, and no systemd because embedded environment resource constraints? There must be a process to init and respawn processes on events like boot (and reboot, if there's a writeable filesystem)
What happened to RustyBox? c2rust is way easier than doing it manually, then why is it abandoned?
OpenWRT has procd instead of systemd, but it does source a library of shell functions and run [somewhat haphazard] /etc/init.d scripts instead of parsing systemd unit configuration files to eliminate shell scripting errors when spawning processes as root.
https://westurner.github.io/hnlog/ Ctrl-F procd, busd
(This re: bootloaders, multiple images, and boot integrity verification: https://news.ycombinator.com/item?id=41022352 )
Systemd is great for many applications.
Alternatives to systemd: https://without-systemd.org/wiki/index_php/Alternatives_to_s...
There are advantages to systemd unit files instead of scripts. Porting packages between distros is less work with unit files. Systemd respawns processes consistently and with standard retry/backoff functionality. Systemd+journals produces indexable logs with consistent datetimes.
There's a pypi:SystemdUnitParser.
docker-systemctl-replacement > systemctl3.py parses and schedules processes defined in systemd unit files: https://github.com/gdraheim/docker-systemctl-replacement/blo...