On Thu, Dec 3, 2020 at 12:48 PM Kevin Ottens <er...@kde.org> wrote: > > Good point. Got a similar question though, which other unit types would be > useful to control? Reason being that API wise I'd smell an enum for something > like this. >
Well if this library would evolve towards C++ API for interacting with systemd, then the following could potentially be useful: - *.timer (cron jobs) - *.scope (confinement to a cgroup) - *.slice (resource partitioning between cgroups) - *.mount (mount options for filesystems) - *.automount (automatically activating a mount for plug and play removable storage without too much fsck risk) - *.service (managing background services) - *.socket (in case your services do things with socket based activation, e.g. dbs) Some of these are obviously already covered, but because I'm not familiar with the KCGroups code base I just listed them for the sake of completeness. Covering them all would give you the basic building block for a GUI for systemd more generally. Additionally, if the "all the wrappers included" approach is taken it might eventually also be worth considering systemd-homed (portable user directories backed by encrypted storage). Regards, - Johan Ouwerkerk
