* Eric Brower <[email protected]> [2010-07-16 12:56:06]: > On Sun, Jul 11, 2010 at 8:07 AM, Lennart Poettering > <[email protected]> wrote: > > On Sun, 11.07.10 19:42, Balbir Singh ([email protected]) wrote: > > > >> > I don't want to go that way. We are not that big a project that it > >> > justifies so many processes. I would rather post patches, merge them > >> > and get more testing feedback. We can always fix bugs later on. > >> > >> We need the feature, but I'd rather make sure it works for everyone, > >> including Lennart before we commit it in. > > > > BTW, I wanted to mention one thing. As you know in the last weeks I > > pointed out to you and primarily to Dhaval a number of things that I > > found missing in libcgroup. For example on Friday I noticed another > > problematic limitation of libcgroup which is that I can only enumerate > > tasks, not processes which are very often much more useful -- even > > though cgroupfs has "cgroup.procs". Also, that file might have > > duplicates and expects userspace to filter those out, which is not > > implemented in libcgroup. > > > > Everytime one of those issues came up I have a few days later > > implemented minimal versions in the systemd sources, because I needed > > them. Bit by bit this has now gone so far that at this point only three > > libcgroup APIs remain that I actively use: > > > > - cgroup_get_subsys_mount_point() > > - cgroup_walk_tree_begin()/cgroup_walk_tree_next() > > - cgroup_delete_cgroup_ext() > > > > And tbh at this point I really wonder if these three APIs still justify > > that systemd links against libcgroup at all because quite frankly I > > don't see that I might port all the calls I implemented in systemd back > > onto libcgroup should libcgroup catch up and provide that functionality > > natively. Maybe it is a better idea to just do the clean cut and remove > > the libcgroup dependency systemd has entirely... > > > > I can understand if this might be disappointing to you, > > > > Sorry, > > > > Lennart > > > > -- > > Lennart Poettering - Red Hat, Inc. > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by Sprint > > What will you do first with EVO, the first 4G phone? > > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > > _______________________________________________ > > Libcg-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/libcg-devel > > > > Sorry to commandeer the prior thread, but this dovetails with a > question I have been asking myself regarding adoption of libcgroup as > a dependency for a current project. > > Looking at a few other projects that would benefit from a cgroup > configuration library, it seems neither are currently using it: > > - LXC: uses hand-rolled support for cgroups > - libvirt: Red Hat RPM "%requires" libcgroup but doesn't actually use > the library (hand-rolled) > > Common use of a cgroup library would undoubtedly be beneficial (esp. > given the current haphazard implementation of individual control group > configuration nodes); being somewhat new to the libcgroup list, could > somebody clarify if there are discussions or plans under way to get > other projects to leverage this library? If not, do we understand > what is stifling adoption? > > No offense intended here-- I'm simply curious about the history and > future direction as I evaluate options. >
Hi, Eric Both these projects are aware of libcgroup, at this point their usage of cgroup is very limited. libvirt uses libcgroup for configuration (please see http://berrange.com/posts/2009/12/03/using-cgroups-with-libvirt-and-lxckvm-guests-in-fedora-12/). Once we have a feature called layer-2 API, we'll be able to ask them to merge with libcgroup once again and see where that leads to. -- Three Cheers, Balbir ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Libcg-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libcg-devel
