Hi Andreas,
Le samedi 21 décembre 2013 à 08:48 +0100, Andreas Barth a écrit :
1. Does systemd (or a part of the systemd project) need to be the
single cgroup writer and if so, why?
It does not… so far. The only thing currently required is for cgroups
consumers to adhere to the shared guidelines¹ different projects agreed
upon. As of today, there is no impact for us.
What is changing is that the kernel cgroups developers want to fix the
current mess cgroupfs has become². The identified solution is to only
allow one cgroupfs hierarchy to be mounted and to let it be managed only
by one process. The future kernel API has not been completely stabilized
yet, but that much is clear.
If you use systemd, this cgroups arbitrator has to lie in systemd
itself. This is because systemd already starts all services as part of
cgroups from PID 1. Otherwise, you can use another arbitrator such as
cgmanager. Both have chosen the approach to provide the cgroups
functionality as a D-Bus API to cgroups consumers (which makes a lot of
sense).
As I understand the transition plan, it goes this way:
1. Migrate cgroups consumers to a D-Bus API instead of using
cgroupfs directly.
2. Stabilize the new kernel API and start providing it in the
kernel.
3. On a switch day, the cgroups arbitrator starts mounting cgroupfs
with the new API. Consumers still accessing the old API stop
working.
4. The old kernel API is deprecated and eventually removed in the
distant future.
Systemd developers are getting ready to part 3 by working closely with
the kernel cgroups developers. It is not clear to me whether cgmanager
will be able to do the same: from my discussions with more knowledgeable
people, it is merely exposing the current cgroups API in D-Bus calls.
This approach cannot work transparently when the API changes. Therefore,
we might only have one available cgroups arbitrator in the end: systemd.
① http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups/
②
http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign
2. What problems do arise from there for other parts of the linux
ecosystem?
These other parts have to migrate to a D-Bus-based interface. The
problem is that systemd and cgmanager developers have not been able so
far to agree on a common API. The consequences for those
cgroups-consuming services are easy to infer.
* Some services will only support systemd.
* Some will use more complex code in order to support both.
* Some will wait until a “standard” emerges and will not work
towards the transition.
With the systemd API being already available³ and part of the stability
promise⁴, the only way this can happen is for cgmanager to start
providing a systemd-compatible API, which in turn is unlikely since
these are just extensions to the base API controlling systemd itself.
Expect Red Hat, Samsung or Intel to provide patches if one of their
products includes a relevant package. I think this is already the case
for libvirt and LXC.
③ http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
④
http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/
Cheers,
--
.''`. Josselin Mouette
: :' :
`. `'
`-
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1387628136.24917.40.camel@tomoyo
