From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757548AbbCCWVD (ORCPT ); Tue, 3 Mar 2015 17:21:03 -0500 Received: from plane.gmane.org ([80.91.229.3]:35320 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757377AbbCCWVC (ORCPT ); Tue, 3 Mar 2015 17:21:02 -0500 X-Injected-Via-Gmane: http://gmane.org/ To: linux-kernel@vger.kernel.org From: Luke Leighton Subject: Re: [Workman-devel] cgroup: status-quo and userland efforts Date: Tue, 3 Mar 2015 22:20:52 +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> <20130628090910.GB2507@redhat.com> <20130628155306.GC26841@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 Daniel P. Berrange (berrange@...): > > Are you also planning to actually write a new cgroup parent manager > > daemon too ? Currently my plan for libvirt is to just talk directly > > I'm toying with the idea, yes. (Right now my toy runs in either native > mode, using cgroupfs, or child mode, talking to a parent manager) I'd > love if someone else does it, but it needs to be done. > > As I've said elsewhere in the thread, I see 2 problems to be addressed: > > 1. The ability to nest the cgroup manager daemons, so that a daemon > running in a container can talk to a daemon running on the host. This > is the problem my current toy is aiming to address. But the API it > exports is just a thin layer over cgroupfs. cool! that's funny, that sounds exactly like what i asked if you could provide, and it turns out that you already did :) so, in theoorryy..... you could have this: * run the service on top of /dev/cgroups, republishing [a subset?] as /run/cgroups and some other parts as /run/cgroups2 * have PID1, instead of going directly to /dev/cgroups, to go to /run/cgroups *instead*. * have lxc, instead of going directly to /dev/cgroups, to go to /run/cgroups2 *instead*. the problem: as lennart mentions, PID1s such as systemd may be expecting to manage the setup of cgroups - entirely - for security or other initialisation reasons - *before* even the service that you've created, serge, is allowed to run. and *that's* why i suggested the idea of following what SE/Linux has done, which is to have policy files that compile down to a set of permissions that the (various) managers can and cannot do. bits of cgroup that they are and are not permitted to manage. flat at the kernel implementation level; hierarchical (or other) at the "compile-the-policy-file" level. l.