KCGroups in KDEreview

[David Edmundson]

On Thu, Dec 3, 2020 at 11:48 AM Kevin Ottens <ervin at 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 at 1000.service
user.slice/user-1000.slice/user at 1000.service/app.slice
user.slice/user-1000.slice/user at 1000.service/session.slice
user.slice/user-1000.slice/user at 1000.service/background.slice
(where 1000 is of course dynamic)