Messages in this thread | | | From | Luke Leighton <> | Subject | Re: cgroup: status-quo and userland efforts | Date | Tue, 3 Mar 2015 22:08:10 +0000 (UTC) |
| |
Tejun Heo <tj@...> writes:
> > Hello, Serge. > > On Thu, Jun 27, 2013 at 08:22:06AM -0500, Serge Hallyn wrote: > > At some point (probably soon) we might want to talk about a standard API > > for these things. However I think it will have to come in the form of > > a standard library, which knows to either send requests over dbus to > > systemd, or over /dev/cgroup sock to the manager. > > Yeah, eventually, I think we'll have a standardized way to configure > resource distribution in the system. Maybe we'll agree on a > standardized dbus protocol or there will be library, I don't know; > however, whatever form it may be in, it abstraction level should be > way higher than that of direct cgroupfs access. It's way too low > level and very easy to end up in a complete nonsense configuration.
just because it sounds easy to end up in a complete nonsense configuration does not mean that the entire API should be abandoned.
instead, it sounds to me like there should be explicit policies (taking a leaf out of SE/Linux's book) on what is and is not permitted.
i think you'll find that that is much more acceptable [to have explicit policy files which define what can and can't be done].
it then becomes possible to define "sensible and sane" default policies for the average situation, whilst also allowing for more complex cases to be created by those people who really really know what they're doing.
the "ridiculous counterexample" to what you are suggesting is that just because "rm -fr /*" does such a lot of damage, rm should have its "-r" option removed. perhaps a better example would involve rsync, which even as far back as 1999 had already run out of lowercase _and_ uppercase letters to use as options... but i can't think of one because rsync is awesome :)
l.
| |