[systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
Martin Steigerwald
Martin at lichtvoll.de
Tue Oct 21 02:41:41 PDT 2014
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
More information about the systemd-devel
mailing list