On Sat, Jul 17, 2010 at 5:15 AM, Balbir Singh <[email protected]> wrote: > * 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 >
Hi Balbir, I've seen some of the patches floated by this list late 09/early 2010-- is there a public repository into which these are being committed? I don't see these changes within the libcg sf.net repositories. Thanks, -- E ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ _______________________________________________ Libcg-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libcg-devel
