On Wed, Jan 14, 2009 at 11:29:40PM +0530, Balbir Singh wrote: > * Dhaval Giani <[email protected]> [2009-01-14 23:12:00]: > > > On Wed, Jan 07, 2009 at 11:35:21PM +0530, Sudhir Kumar wrote: > > > This is a try to use a sample configuration file for running libcgroup > > > testing. The patch attaches a sample configuration file to be used. The > > > plan for testing each input api is to run a particular funcition with > > > respect to that api. The function is supposed to test all possible > > > scenarios for that api.(e.g. calling api without initializing cgroup, > > > with diff invalid/NULL parameters, calling it twice etc). > > > > > > I have couple of doubts with respect to the implementation: > > > 1. How should the test be run? A script running the binary or just > > > binary? > > > 1a. If only binary then we may need a small string library as there > > > will be lot of string manipulations while parsing. > > > 1b. If a script then how to fill data structure of binary if we parse in > > > script. > > > > > > 2. How to ensure a clean state of the system in case of some failure. > > > 3. Shall I put separate options in .conf file for no,single and > > > multimount. > > > 4. I am thinking to take input from user for the number of instances of > > > test to be run. For ex if I say > > > api,cgroup_create_cgroup,15 > > > then there will be 15 tasks in the task list running the corresponding > > > function. Is that good? > > > 5. Any other fields that need to be added. > > > > > > > > Sudhir, > > I don't like the format very much, I had something like the following > in mind > > [test] > id = 1 > name = "something" > threads = 10 > process = 10 What is the idea here ? > mount = "cpu, memory" > cpu.shares = "nnnn" > memory.limit_in_bytes = "lllll" So here is again a deal. How to know which control file belongs to which controller? If I use the preceding name(eg if cpu.* then controller is cpu), then the test needs to have alist of all the possible controllers. Or I have the string of controllers specified in mount ="" and I create a list from it. Using a keyword before each set of parameters looks helping in parsing. However I have no idea what can be the side affect of it. In my views if we do not have a set of keywords we will be executing more iterations of parsing code.(hope i am not going much into implementation...)
The other question: We have four possible ways to set control values as per libcgroup wrapper apis. Why not we use them, at least from the code path execution point of view ? > cleanup = true Agree. > > > and then use that for the tests, note the parameters are optional. You > could even go one step ahead and specify a flow. We should definitely > specify a parameter in the form of cleanup. I expect the configuration > file to be parsed by a shell script or a simple "C" program. If a > script parses it, it can specify this as parameters to the tests it > invokes. > > You could go one step further and specify the test cases directly > (provided the infrastructure can handle/support it) > > process = 10 > threads = 15 > [test flow] > cgroup_name="001" > cgroup_create_cgroup:p > cgroup_create_cgroup:f So this part is again more complex. The reason is that the pass and failure of a particular api, highly depends on the order of execution of the api. How do we handle all those scenarios? For example: If I say test the api cgroup_modify_cgroup() There can be lot of scenarios as 1. Call without calling init() api. 2. Call without calling create() api. 3. Call with many types of wrong arguments to the api. ....etc So how do we take care of all those scenarios. My idea here was that we will define a function like test_cgroup_modify(), which will call the api under all possible scenarios and give the results.(so here we do not have a single return value and hence passing p or f does not make much sense) However I am open to any better ideas. > ... > > etc, where p and f represent expected return code "pass" or "fail", > but I'd add test flow only much later, since it would need more formal > design and thought. > > I hope I answered your questions Thanks for that -- Regards Sudhir Kumar Linux Technology Center IBM, India. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Libcg-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libcg-devel
