[systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance

[Martin Steigerwald]

Am Dienstag, 21. Oktober 2014, 11:26:16 schrieben Sie:
> On Tue, Oct 21, 2014 at 11:08 AM, Martin Steigerwald
> 
> <Martin at lichtvoll.de> wrote:
> > Then systemd may use it as PID 1, but if someother wants to use it in own
> > project, can use it as well. I consider cgroups as part of the kernel API
> > and I highly dislike the battle on which of the available solutions will
> > get control over it. Actually I still think the API is broke if it cannot
> > allow for mutiple processes accessing it. I don´t know an easy way to fix
> > it, but I think such a kind of API as kernel interface… anyone can read a
> > file, mount a filesystem, open a network socket, set a nice value
> > depending on permissions but when it comes to control groups it is down
> > to "one to rule them all". I can´t help it, but this just seems utterly
> > broke to me.
> > 
> > I can´t help it but I don´t consider this to be a sane operating system
> > API.
> Note that the maintainers of the kernel-side cgroup API (primarily
> Tejun Heo, AFAIK) consider the current interface insane. In the
> future, the kernel will expect a single userspace process to control a
> single hierarchy. Systemd has already been adapted to provide this
> schema using the current API. See
> http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html

Well I concur with that.

I think the mutiple hierarchy API is inconsistent and insane. I see the point 
of having a unified hierarchy. But I never understand the requirement of one 
process controlling it and then having a battle over which process it will be.

Whereever else we had something like this, it was tightly reduced to one 
functionality and available separate. Like udev, but still tightly coupled 
with the kernel and free to anyone to use – *just* this part of the 
functionality. Just like the Performance Events with the perf tools. Or 
iproute. Or you name it: Everyone providing one functionality. And… in its 
part being replacable.

But with systemd it appears to be an all or nothing approach. I don´t only get 
control groups, but everything else… or else I need to duplicate the 
functionality myself.

That just doesn´t make any sense to me. For udev I had the impression it was 
some quite approved part of the Linux kernel userspace utility.

So while I think the old mutiple hierarchy API is broke, and heck I teached it 
in my Linux Performance analysis and tuning courses… I do think the new API is 
broke as well.

Sometimes I think better ditch it all and redo it from scratch.

Anyone can open a file, mount a fs, set a nice value, but only one process can 
do resource control of process groups via cgroups. This doesn´t make any sense 
to me.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7