From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932576AbbCCWIY (ORCPT ); Tue, 3 Mar 2015 17:08:24 -0500 Received: from plane.gmane.org ([80.91.229.3]:34484 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932082AbbCCWIX (ORCPT ); Tue, 3 Mar 2015 17:08:23 -0500 X-Injected-Via-Gmane: http://gmane.org/ To: linux-kernel@vger.kernel.org From: Luke Leighton Subject: Re: cgroup: status-quo and userland efforts Date: Tue, 3 Mar 2015 22:08:10 +0000 (UTC) Message-ID: References: <20130406012159.GA17159@mtj.dyndns.org> <20130422214159.GG12543@htj.dyndns.org> <20130625000118.GT1918@mtj.dyndns.org> <20130626212047.GB4536@htj.dyndns.org> <1372311907.5871.78.camel@marge.simpson.net> <20130627132206.GE4003@sergelap> <20130627174850.GC5599@mtj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 217.147.94.29 (Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.1.0) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tejun Heo 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.