On Mon, Jun 24, 2013 at 4:19 PM, Tejun Heo <t...@kernel.org> wrote: > Hello, > > On Mon, Jun 24, 2013 at 04:01:07PM -0700, Andy Lutomirski wrote: >> So what is cgroup for? That is, what's the goal for what the new API >> should be able to do? > > It is a for controlling and distributing resources. That part doesn't > change. It's just not built to be used directly by individual > applications. It's an admin tool just like sysctl - be that admin be > a human or userland base system. > > There's a huge chasm between something which can be generally used by > normal applications and something which is restricted to admins and > base systems in terms of interface generality and stability, security, > how the abstractions fit together with the existing APIs and so on. > cgroup firmly belongs to the former. It still serves the same purpose > but isn't, in a way, developed enough to be used directly by > individual applications and I'm not even sure we want or need to > develop it to such a level.
My application is running on a single-purpose system I administer. I guess what I'm trying to say here is that many systems will rather fundamentally use systemd. Admins of those systems should still have access to a reasonably large subset of cgroup functionality. If the single-hierarchy model is going to prevent going around systemd and if systemd isn't going to expose all of the useful cgroup functionality, then perhaps there should be a way to separate systemd's hierarchy from the cgroup hierarchy. Looking at http://0pointer.de/blog/projects/cgroups-vs-cgroups.html, it looks like systemd doesn't actually need the cgroup resource control functionality. Maybe there's a way to disentangle this stuff. The /proc/<pid>/children feature that CRIU added seems like a decent start. --Andy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
