KCGroups in KDEreview

[Kevin Ottens]

On Sunday, 13 December 2020 22:41:24 CET David Edmundson wrote:
> 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'll be honest I'm still unsure what that'd mean in practice... What about 
drafting API for a couple of those? Let's not get overboard implementing stuff 
and so on, it's more exploratory that anything for now.

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

Ditto, what enum names could we give to those?

Yes, I know I roll with questions. :-)

Cheers.
-- 
Kevin Ottens, http://ervin.ipsquad.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20201214/6431135e/attachment.sig>