On Thu, Dec 3, 2020 at 11:48 AM Kevin Ottens <er...@kde.org> wrote: > > Hello, > > On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote: > > Ultimately this isn't really dealing with cgroups directly but with > > the manager to control them, systemd. > > > > That's correct usage, kernel docs of cgroups say to go via a > > controller for write operations. However that at point is it worth > > naming the library ksystemd? > > It might cause some contention due to people who get angsty at a name, > > but it's a lot more fitting. It would then give us a place to dump a > > lot of other wrappers (especially logind) that we're seeing duplicated > > in a bunch of places throughout KDE. > > Aren't you concerned this might lead to one of our infamous dumping grounds? > > There's always a tension between making it too focused and tiny or unfocused > and with blackhole mass... we'd need to find where it stands but "systemd > wrappers" looks too loosely defined to me. >
> Do we have a list of the wrappers you got in mind and which piece of feature > they all provide? StartUnit, given this has a StopUnit Used by plasma-workspace and plasma-firewall Logind I have wrappers in: - kwin - libkworkspace - SDDM - powerdevil - kscreenlocker None wrapping all of it, only what they need, but there's still overlap. You're right that could be a separate framework if that's preferred. > > > I think we've artificially limited the usage of the library. > > The code is very generic for handling units, but all the names and one > > tiny line limit it to only managing a subset of units. > > > > If we make the "glob" static used in KApplicationScopeLister's have a > > public setter (or a protected virtual) we can rename this class and it > > becomes a much more generic library for others to use outside of any > > initial use-case. > > 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. Enum potentially works too. Describing things in terms of cgroup hierarchy, I think the key use cases are: / user.slice/user-1000.slice/user@1000.service user.slice/user-1000.slice/user@1000.service/app.slice user.slice/user-1000.slice/user@1000.service/session.slice user.slice/user-1000.slice/user@1000.service/background.slice (where 1000 is of course dynamic)