Dan Smith wrote: > 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. > We intend to do that so that we have stable API. > 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. > We've generally honoured all requests on the mailing list and request for new API. I've generally seen you help review code or find problems, we also encourage code contributions to fix any problems you see. > 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. And this would be lesser effort than contributing code to libcgroup to fix the problems you see? Library design is hard and were fixing things, getting them to work together. Libcgroup is an open project and no-one stops you from fixing problems you see or adding new features or even rewriting the whole thing. When the libcgroup API and > functionality settles a bit, it should be easy to start using it. > I would prefer we use libcgroup now, instead of rewriting to use libcgroup later. It seems like a lose-lose situation to me. -- Balbir -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list