[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: KCGroups in KDEreview
From:       Kevin Ottens <ervin () kde ! org>
Date:       2020-12-03 11:48:13
Message-ID: 34207352.7bdt7OMHP1 () wintermute
[Download RAW message or body]


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

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]