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@xxxxxxxxxx
Attachment:
pgpsiDYvgSNSp.pgp
Description: PGP signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list