On Sat, 2013-10-26 at 08:34 +0300, Uoti Urpala wrote: > Brian May wrote: > > > As much as I would like to see systemd as the default in Debian (and > > have switched to it on my Desktops), I see two show stopper issues: > > > > > > * Needs to work (somehow) with other applications (including not in > > Debian) that need to manage cgroups. In Debian this would include lxc. > > My understanding is that the _kernel_ side wants to change the cgroup > API, and this means that at least in the long term current cgroup-using > applications will need to change in any case (possibly by using systemd > APIs instead). [...]
Your understanding seems to be incomplete. There are two architectural problems with the current cgroups API: (1) the multiple types of cgroups form separate hierarchies, which can result in effective conflicts between different cgroup controllers (2) when the cgroupfs is manipulated by multiple tasks, this results in unpleasant race conditions for userland. I think there is agreement in the kernel community that (1) should be fixed by requiring all cgroups to fit into a single hierarchy. There is not yet agreement as to whether (2) should be fixed by (a) putting a single daemon (presumably pid 1) in charge of cgroupfs and having other userland programs make requests to that daemon, or (b) improving the API to make the race conditions avoidable, so control over sub-trees can be safely delegated. There was a discussion of these problems at the Kernel Summit on Thursday and I hope to see a more detailed report in LWN within the next few days. Ben. -- Ben Hutchings Editing code like this is akin to sticking plasters on the bleeding stump of a severed limb. - me, 29 June 1999
signature.asc
Description: This is a digitally signed message part
