On Tue, Jul 27, 2010 at 7:05 AM, Nikunj A. Dadhania <[email protected]> wrote: > On Mon, 26 Jul 2010 10:48:59 +0200, Dhaval Giani <[email protected]> > wrote: >> Signed-off-by: Dhaval Giani <[email protected]> > >> +struct cgroup_context_s { >> + char *cg_namespace[CG_CONTROLLER_MAX]; >> + struct cg_mount_table_s mount[CG_CONTROLLER_MAX]; >> + unsigned size; >> +}; > CG_CONTROLLER_MAX is set at 100, can we do something like this? > > enum { > CG_CPU, > CG_MEMORY, > CG_IO, > CG_CPUSET, > /* all controllers go here */ > > /* Last in the enum list */ > CG_CONTROLLER_MAX > }; > > This will make sure that we do not do excessive allocations, as this struct is > going to be allocated per thread. >
I am bit worried about ABI breakage as we add more controllers, and then we start getting into this problem that older versions of libcgroup cannot be used with newer controllers and the likes (sure, we would like them to use the newer version, but sometimes... ). Similarly libcgroup will have to be modified to be used with a development kernel. Not to mention that we have named hierarchies which might not have any controllers attached to them. (systemd makes use of them) So I am not inclined to follow the enum method. There might be a smarter way, sure. Might make sense to use pointers and dynamically allocate it at some point in time. But at this point, I would rather have working code, and then work on fixing up these issues. Dhaval ------------------------------------------------------------------------------ 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
