On Sunday, 13 December 2020 22:41:24 CET David Edmundson wrote: > 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'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@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) Ditto, what enum names could we give to those? Yes, I know I roll with questions. :-) Cheers. -- Kevin Ottens, http://ervin.ipsquad.net
signature.asc
Description: This is a digitally signed message part.