Re: [LTP] RFC : refactor LTP execution model

[Rishikesh K Rajak <risrajak@linux.vnet.ibm.com>]

Hi Garret,

My point will still not be so much useful for you but i tried to understand your
proposal last weekend and thought to reply you. May be Subrata can give
you much input here as he is with this project from long time.

>   My proposal is as follows:
>
>   1. A discrete set of reporting functions should be created (error,
>info,
>warning, etc). This messages should adhere to the following basic
>paradigm:
>       error - always displayed.
>       info - only displayed when quiet isn't used.
>       warning - only displayed when quiet isn't used.
>       That way folks could
>

Hmm.... that's way we can give crisp info to user, but what about TBROK
tetscases ? Are we going to categorize that in error ?

>   2. runltp be split into discrete functional blocks, as follows:
>       i.   Parse core options. Parse any additional options for
>functionality like email, HTML output, etc.
>       ii.  Prepare the tests based on the runtests files and options
>passed
>in (run valgrind on the tests, etc).
>       iii. Basic setup.
>       iv.  Execute the tests.
>       v.   Basic teardown.
>       vi.  Output methods for email, HTML, etc.
>
So are you proposing for writing all new scripts ? Did not quite
understand what could be the motive behind it. We are already having
runalltest.sh , which does this segregation for user whether he wants an
email, HTML or not.

>    So when runltp is executed, it does something like the following:
>    1. source testscript [if it exists].
>    2. Change the test ``execution plan'' so that they setup and
>teardown
>inexplicably executed in the following manner (following Java's
>unit-test
>and python unittest):
>
>    Setup the test; if successful, continue on with the test(s) and
>teardown
>at the end.
>
    The purpose for making this into a script as opposed to any other
>sort
>of metadata, is that anyone executing the tests standalone will only
>need to
>source the script to set everything up, then execute the test itself.
>    The only thing that might be a problem is that runtest files are
>mashed
>together if multiple runtest scenario files are specified. This
>shouldn't be
>an issue though if everything is strung together properly via the calls
>above (setup, test, teardown).
>    Thoughts?

Overall nice proposal, i also could not understand this "teardown" concept.

-- 
Thanks & Regards
Rishi
LTP Maintainer
IBM, LTC, Bangalore
Please join IRC #ltp @ irc.freenode.net

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list