public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Subrata Modak <subrata@linux.vnet.ibm.com>
To: Paul Larson <paul.larson@ubuntu.com>
Cc: Sachin P Sant <sachinp@linux.vnet.ibm.com>,
	LTP Mailing List <ltp-list@lists.sourceforge.net>,
	Mike Frysinger <vapier@gentoo.org>,
	Michael Reed <mreed10@us.ibm.com>, Nate Straz <nate@refried.org>,
	Manoj Iyer <manoj.iyer@ubuntu.com>,
	Balbir Singh <balbir@linux.vnet.ibm.com>
Subject: Re: [LTP] [PATCH 05/05] Add the necessary Interface and Option	through "runltp"
Date: Wed, 12 Aug 2009 16:51:03 +0530	[thread overview]
Message-ID: <1250076064.5373.23.camel@subratamodak.linux.ibm.com> (raw)
In-Reply-To: <4A81B1A0.5050708@ubuntu.com>

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


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

  parent reply	other threads:[~2009-08-12 11:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-11 17:29 [LTP] [PATCH 00/05] Integration of "Fault Injection Framework" into LTP Subrata Modak
2009-08-11 17:30 ` [LTP] [PATCH 01/05] Provide all necessary information through ltp/README Subrata Modak
2009-08-11 17:30 ` [LTP] [PATCH 02/05] Add Script which would actually do the job of injecting faults Subrata Modak
2009-08-12  8:45   ` Garrett Cooper
2009-08-12 11:20     ` Subrata Modak
2009-08-11 17:30 ` [LTP] [PATCH 03/05] Add Script so the kernel is restored back to its original pristine form Subrata Modak
2009-08-11 17:30 ` [LTP] [PATCH 04/05] Add Script which will be at the heart of this infrastructure Subrata Modak
2009-08-12  8:42   ` Garrett Cooper
2009-08-12 11:21     ` Subrata Modak
2009-08-13  7:11       ` Mike Frysinger
2009-08-11 17:31 ` [LTP] [PATCH 05/05] Add the necessary Interface and Option through "runltp" Subrata Modak
2009-08-11 18:02   ` Paul Larson
     [not found]   ` <4A81B1A0.5050708@ubuntu.com>
2009-08-12 11:21     ` Subrata Modak [this message]
2009-08-13  7:13   ` Mike Frysinger
2009-08-11 17:31 ` [LTP] [RESULTS] Results of test run for "Fault Injection Framework" Subrata Modak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1250076064.5373.23.camel@subratamodak.linux.ibm.com \
    --to=subrata@linux.vnet.ibm.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=manoj.iyer@ubuntu.com \
    --cc=mreed10@us.ibm.com \
    --cc=nate@refried.org \
    --cc=paul.larson@ubuntu.com \
    --cc=sachinp@linux.vnet.ibm.com \
    --cc=vapier@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox