Re: [LTP] [PATCH 05/05] Add the necessary Interface and Option through "runltp"

Subrata Modak
2009-08-12T11:21:41Z

Hey Paul,

Thanks for taking out time to reply.

On Tue, 2009-08-11 at 13:00 -0500, Paul Larson wrote:
> Subrata Modak wrote:
> ...
> > + -F LOOPS,PERCENTAGE Induce PERCENTAGE Fault in the Kernel Subsystems, and, run each test for LOOPS loop
>
> I haven't had time for an exhaustive review, but here are a few
> questions/comments I had:
>
> 1. Why introduce yet another looping mechanism within LTP when we
> already have one? Is there an advantage that you see to doing it this

I am not using additional mechanism to generate LOOPS. Itś like the
script just reads each line of entry in the command file, then just
rewrites that line with the following n+1 entries:

1) 1st entry exactly same as the original one. Meant to see the test
output in normal kernel,
2) n entries run within the fault kernel and fault withdrawn immediately
after the nth entry is written.

Here, ltp-pan doesn´t even know who generated & withdrew these faults
and how those loops came into being. In all other cases of loop
generation, ltp-pan and runltp has knowledge, here they do not.

Here we want to run few loops(chosen by the user) of the same test under
faulted kernel to make sure that the test is exhibiting some abnormal
behaviour under the faulted kernel, which may not be possible if just 1
loop is run under fault.

> way, rather than just having an additional option that calls the script
> to generate this additional random fault injection?
>
> 2. Would be good to push the check for /debug being mounted down into
> one of the other scripts rather than in runltp. runltp is already
> hideously bloated and this would make it more useful when running
> standalone.

Hmmm. I will look into this.

>
> 3. would be great if there were some way to tag the results to say when
> a fault was or was not in the process of being generated. That is,
> perhaps, not possible at this time though.

Goog suggestion though. Probably i need to change the way tags are
generated, i can just replace:
tag_name_loop(n)
with
tag_name_loop(n)_kernel_under_fault
sort of stuff.

>
> 4. more granularity possible with the fault injections to specify the
> type of faults, or optionally, the behaviour you have here?

Yes. These enhancements are possible to be done in future. I wanted to
use all the faults provided by the kernel at the time being.

Regards--
Subrata

>
> Thanks,
> Paul Larson