KCGroups in KDEreview

Martin Steigerwald martin at lichtvoll.de
Thu Dec 3 11:55:58 GMT 2020

>From a user's point of view (who helps with triaging bugs and some other 
stuff from time to time), so feel free to consider it or not.

David Edmundson - 03.12.20, 12:15:52 CET:
> 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?

I'd say that depends on whether it at some point could be extended to 
support another cgroups controller daemon or not. I don't see any 
popular one at this point in time, however this might change.

> 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.

Of course if you like to extend it more towards systemd, a name change 
would make sense.

While I know and teach what control groups can do, I do not really care 
about the functionality they offer at the moment on my desktop machines. 
I use elogind with Plasma both on Debian Sid and on Devuan Ceres which 
sets up a CGroup V2 structure by default, but does not do any of the 
resource control stuff that Systemd offers.

Control groups, logind and things like that sounds like integration with 
services and functionalities of the host operating system. So I wondered 
whether it would make sense to generalize that. However, that might just 
be too much abstraction. There is Phonon, which does that for audio, but 
basically I just used whatever backend was recommended at a time. And 
AFAIR there has been times where one of the backends did not even work 
correctly for some reason.


More information about the kde-core-devel mailing list