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
