Hello everyone. This came up in the course of something else, and it was
suggested I bring it here for discussion. I think there's some room for
improvement in the cgconfig config file. This will make the file much more
accessible to administrators, making the toolset get used more, and everyone
wins.
So, the concrete suggetions:
a) Remove the need for semicolons at the end of lines.
b) Put the mount section and the group sections in different files. This
immediately removes the need for one level of hierarchy. (It also
provides a migration path -- the tools can continue to understand the old
file if it exists.)
c) With its own separate config file, the mount section can now just be
individual lines of "<controller> = <path>".
d) In the group config file, {} might be okay for defining each
particular group. But rather than having one file with lots of {}
sections, it'd be even better to have a separate file for each group.
This makes maintenance via scripts or rpms much easier. Put them all
under a directory like "/etc/cgroup/groups.d/", and read in every file
there with a .conf extension.
e) In the group permissions, rather than a struct-like hierarchical
definition, do this in two flat lines:
cgroup-owner = <uid>[:<gid>]
tasks-owner = <uid>[:<gid>]
(Not "tasks" instead of "task", since it matches the actual filename,
and simply "cgroup" instead of "admin" for similar reasons.)
or if you prefer:
cgroup-owner = <uid>
cgroup-group = <gid>
tasks-owner = <uid>
tasks-group = <gid>
f) In the controller section for a group: it is my impression that all of
the parameters for a given controller already begin with the name of that
controller. Therefore, it's unnecessarily verbose to have a { } enclosure
with the name of the controller, right? Except that an *empty* section
actually means something, which is a fact I only caught on reading the
documentation over twice. So, there's two things. First, a line defining
the controllers for this group:
controllers = <controller> [, <controller>] [...]
and then any parameters:
<controller.param name> = <param value>
one per line.
So to put that all together, here's the overall suggested syntax:
/etc/cgroup/cgroup.mounts:
<controller> = <path>
...
(Note that this could also be done with /etc/group/mounts.d instead. Also,
my understanding is that if controllers are already mounted, libcgroup
will just use those. So on installations/distributions where they're
already getting mounted, this file could be nonexistent.)
/etc/cgroup/groups.d/*.conf:
[name = <name>] # defaults to filename without .conf
[cgroup-owner = <uid>] # defaults to root
[cgroup-group = <gid>] # defaults to root
[tasks-owner = <uid>] # defaults to cgroup-owner
[tasks-group = <gid>] # defaults to cgroup-group
[controllers = <controller> [, <controller>] [...] ] # defaults to kernel
parameters
[<controller.param name> = <param value>]
[...]
What do you think? Thanks!
--
Matthew Miller <[email protected]>
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
_______________________________________________
Libcg-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libcg-devel
