DB> I believe Daniel is refering to the struct's in your public header
DB> file. The embedded comments themselves in libcgroup.h say that the
DB> structs will need to be extended with more fields as cgroups gets
DB> more capabilities. Adding fields to a struct will change the ABI
DB> unless care is taken to provide for extensibility. The
DB> cpu_controller and cg_group structs here are of particular concern
I think that these structures in the header file are all cruft. There
are access functions to eliminate the need to know the format of the
data structures. I'm not aware of any public users, but there is
already a maintained set of deprecated APIs for some of this. IMHO,
this is indicative of the current process of evolution that libcgroup is
struggling with.
I think the problems run a little deeper than that, and that they have
been comprehensively discussed on libcg-devel already. I definitely
think that a cgroup abstraction is beneficial, but I don't think it's in
a terribly useful spot at the moment.
Having monitored and participated with the libcgroup development pretty
closely thus far, I'd say that going forward with an internal
mini-implementation is a sane thing to do at this point to get working
cgroup support in a timely fashion. When the libcgroup API and
functionality settles a bit, it should be easy to start using it.
--
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms(a)us.ibm.com