From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757856AbbCCWAu (ORCPT ); Tue, 3 Mar 2015 17:00:50 -0500 Received: from plane.gmane.org ([80.91.229.3]:34031 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757750AbbCCWAs (ORCPT ); Tue, 3 Mar 2015 17:00:48 -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:00:24 +0000 (UTC) Message-ID: References: <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> <20130627161809.GA4957@sergelap> 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 Serge Hallyn writes: > > Quoting Tim Hockin (thockin@...): > > > FWIW, the code is too embarassing yet to see daylight, but I'm playing > > > with a very lowlevel cgroup manager which supports nesting itself. > > > Access in this POC is low-level ("set freezer.state to THAWED for cgroup > > > /c1/c2", "Create /c3"), but the key feature is that it can run in two > > > modes - native mode in which it uses cgroupfs, and child mode where it > > > talks to a parent manager to make the changes. > > > > In this world, are users able to read cgroup files, or do they have to > > go through a central agent, too? > > The agent won't itself do anything to stop access through cgroupfs, but > the idea would be that cgroupfs would only be mounted in the agent's > mntns. My hope would be that the libcgroup commands (like cgexec, > cgcreate, etc) would know to talk to the agent when possible, and users > would use those. serge, i realise this is a year on, so you probably have something at least working by now... but i have a possibly crazy idea.. would it be possible or convenient for the agent that you are writing to emulate - in userspace - the *exact* same interface as /dev/cgroups, providing a controlled hierarchy yet presenting itself to other processes in such a way that its hierarchical management would be completely transparent to anything that used it? including of course a new instance of the agent itself, in a recursive fashion :) the important question on top of this would be: is there anything that needs to be atomic which emulation of the /dev/cgroups kernel API in userspace could not handle? l.