On Fri, 2008-11-14 at 17:51 +1100, David Gibson wrote: > On Thu, Nov 13, 2008 at 08:26:12PM +0000, Adam Litke wrote: > > Now that libhugetlbfs can work with multiple huge page sizes, testing this > > support has become a priority. The following patch enables automatic > > testing > > of page sizes that are mounted and have at least one page allocated. Care > > is > > taken to assure that only valid combinations are tested. For example, 32bit > > tests are not run with 16GB pages. Following the run, a summary of all page > > sizes tested is printed. The following is some example output of the new > > script: > > > > ********** TEST SUMMARY > > * 64K 16M 16G > > * 32-bit 64-bit 32-bit 64-bit 32-bit 64-bit > > * Total testcases: 86 89 86 89 0 89 > > * Skipped: 20 0 20 0 0 0 > > * PASS: 59 75 62 85 0 49 > > * FAIL: 5 6 1 1 0 29 > > * Killed by signal: 0 0 0 0 0 0 > > * Bad configuration: 2 2 3 3 0 10 > > * Expected FAIL: 0 0 0 0 0 0 > > * Unexpected PASS: 0 0 0 0 0 0 > > * Strange test result: 0 6 0 0 0 1 > > ********** > > > > Script programming language conversion alert: > > > > This patch rewrites run_tests.sh in python. I already anticipate the "why > > change languages" comments so I come prepared with justification for the > > conversion. Our test harness has extended beyond simply executing a list of > > test cases and dumping the output to stdout. The data set for the test > > summary > > is now three-dimensional. It is indexed by result type (total tests, total > > passed, etc), word size, and now page size. The simple arrays in bash are > > not > > up to the task. As the number of tests that are run increases, so does the > > challenge of presenting the results in a meaningful, easy to digest format. > > Shell scripts lack the output formatting constructs that are present in > > languages such as Python and that make flexible output formatting possible. > > For these reasons (and the guarantee that the test harness will need to get > > even more sophisticated in the future), I made the inevitable decision to > > cut > > over to Python now. > > Hmm. I was about to say I thought changing to Python was a pretty > good idea, but then I had some second thoughts. > > These are all sound arguments, and the script certainly was getting > pretty messy in shell. I wrote it in shell initially because that was > the simple obvious option when it was just a handful of simple tests. > The testsuite is a lot more complex these days. > > The one big thing that worries me about switching to Python is that it > introduces another build and test dependency. That's not a big issue > for regular desktop or server systems - Python's common enough. But > it is an issue for embedded boards, where hugepage support is becoming > increasingly common. In particular that's troublesome because > libhugetlbfs is de fact the testsuite for kernel hugepage support as > well as for the library itself. Making it harder to do a thorough > test of hugepages on J Random embedded board is a non-trivial > drawback.
Yes, you make a good point here. If the target system lacks Python, could they just use freeze to produce a binary? http://wiki.python.org/moin/Freeze -- Adam Litke - (agl at us.ibm.com) IBM Linux Technology Center ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libhugetlbfs-devel mailing list Libhugetlbfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
