On Thu, Nov 19, 2009 at 7:05 PM, Mark Ver <[email protected]> wrote:
> The number of testcases over the past year had increased faster than could
> be properly debugged by our skeleton team for the s390x platform. Many of
> the testcases seemed to be designed for features on later kernel versions
> with were not yet fully integrated by our supported distributions.
>
> Since we mostly used LTP for a quick regression test, I was discussing with
> Subrata about creating a minimal test set that we expected would run
> properly on a majority of the distributions with kernel 2.6 and not just the
> more recent versions of the kernel.
>
> This is my first pass at the test set:
> (See attached file: s390x_ltpcore_targets)
>
> It is basically a subset of the default SCENFILES from the ltp-full-20090731
> concatenated into one file.
>
> Basic rundown of the contents ...
> * Included tests:
> syscalls
> fs
> fsx
> dio
> mm
> ipc
> sched
> math
> nptl
> pty
> containers
> fs_bind
> filecaps
> fcntl-locktests
> -----
> * Excluded tests - new in 2009 (maybe late 2008) versions (appear to have
> build, run, or support issues depending on distribution release)
> io
> cap_bounds
> connectors
> admin_tools
> timers
> power_management_tests
> numa
> hugetlb
> commands
> hyperthreading
> -----
> * Excluded from original set:
> controllers
> - notes: this feature was currently available only on SLES-11 and the build
> and execution of the testcase appeared to need more work for s390x
> -----
>
> Ideally I was hoping to come up with a set of tests that were so basic, they
> should be supported by practically every release and would be expected to
> run correctly everywhere. They would only fail if major issues had been
> introduced into the system build.
Mark,
An ideal solution to this problem is a two-tiered solution:
1. Feature based conditional compilation.
2. Tool based conditional compilation (some tests require certain
tools, such as perl, python, and various Unix utilities that aren't a
part of the minimal set of tools, e.g. useradd, userdel, etc).
The tool based condition compilation is somewhat simple at a 10k
ft level (I have perl, python, ruby, etc -- add / remove these tests /
features) -- the feature based conditional compilation issue is a bit
more difficult to deal with as it requires a more in-depth
understanding of what code exists in the sourcebase, and what
functional tests map to what functional blocks under test. This is
ideal, but not trivial to perform.
My first goal is to deal with any fallout from the make
infrastructure commit(s), dealing with the make 3.80 incompatibility
and other unforeseen usecases like you have with building and
executing out of the same source tree. Next, I want to clean up any
and all C warnings so the tests are more robust (Mike, Cyril, and I
have done a pretty good job but there's a ways to go...). Then I'll
undertake completing the ballista cleanup, which will also involve
adding the shims for perl and python across the entire sourcebase.
We'll need to revisit the feature based enabling a little later.
How does that sound?
Thanks,
-Garrett
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
