Hello,
after playing a lot with configuration file for cgconfigparser I finally
understood how the groups, mount points and subsystems (controllers)
work together. But I am not sure if it is expected and user-friendly
behavior.
Let's say the user has following config file (sorry, it's a bit long):
group cpu1 {
perm {
task {
uid = jsafrane;
gid = jsafrane;
}
admin {
uid = root;
gid = root;
}
}
cpuset {
}
devices {
devices.deny=a;
}
}
group cpu1/cpu11 {
cpuset{}
}
group cpu1/cpu12 {
cpuset{}
}
mount {
cpuset = /mnt/cgroups/cpu;
devices = /mnt/cgroups/devices;
}
It's pretty simple - it creates /mnt/cgroups/cpu with 'cpuset' hierarchy
and /mnt/cgroups/devices with 'devices'. So far so good.
Now I have some problems understanding the groups. Looking at the config
file, one would say that there is group cpu1 with two subgroups, cpu11
and cpu12. And one would assume, that if cpu1 has denied access to all
devices then also both subgroups have the access denied (as the kernel
doc describes). But they don't! cpu11 and cpu12 are subgroups of cpu1
only in hierarchy related to 'cpuset', they are not related to
'devices'. This is *very* inconvenient and it took me quite a time to
realize what's wrong.
The whole concept of having mounts and groups separated is IMHO not user
friendly. It's hard to say which groups are created in which hierarchies
and what consequences it has. At least it does not correspond to final
directory and kernel data structures.
I would propose different config file structure, let's say something
like this:
mount cpuset,cpuacct {
path=/mnt/cgroups/cpu;
perm { /*... as usual ...*/ }
group cpu1 { /*... parameters as usual */ }
group cpu1/cpu11 { ... }
/* other groups as needed */
}
mount devices {
path = /mnt/cgroups/devices;
perm { /* as usual */ }
/* groups as needed */
}
This would ensure that the two hierarchies are separated and mapping to
filesystem structure and back is clearly visible. A drawback might be
that if a user wants to create groups in both hierarchies, he/she must
create them twice.
I studied the sources quickly and it seems to me it could be possible,
but lot of things needs to be rewritten (e.g. most of the config.c) and
internal data structures would change significantly. I'd volunteer to do
that, if it's worth doing and you'd be interested in such rewrite. (Note
it may take some time to me to do the rewrite, it's lot of code). Btw,
XML config file would IMHO simplify lot of parsing and checking,
wouldn't it?
On the other hand, I could write some documentation (man page?) about
current cgconfig.conf structure, where I would emphasize the strange
behavior described above.
Jan
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Libcg-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libcg-devel
