Am Dienstag, 21. Oktober 2014, 11:26:16 schrieben Sie: > On Tue, Oct 21, 2014 at 11:08 AM, Martin Steigerwald > > <mar...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel