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. Thanks, -- E ------------------------------------------------------------------------------ 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
