* Sudhir Kumar <[email protected]> [2009-01-15 09:34:55]:
> > 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 ?
The idea is to allow a test or a set of tests to run concurrently.
> > 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...)
>
True, but then why do we care about the parameters belong to a
particular controller? Can't we get/set these values and be sure for
the specified mount points they are correct or incorrect (depending on
what we are testing)
> 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 ?
We can consider using them, provided we know they are bug free. We can
test them and via induction assume that if they are bug free, then we
can test other API's further (might be acceptable, unless someone
objects).
> > 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.
>
Agreed, this part is complex, so lets skip it for now.
--
Balbir
------------------------------------------------------------------------------
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
