Adding control file variables (NAME, DOC, etc.)

Signed-off-by: James Ren <[email protected]>

lmbench/control

@@ -1 +1,33 @@
+NAME = "lmbench"
+AUTHOR = "Martin Bligh <[email protected]>"
+TIME = "MEDIUM"
+TEST_CATEGORY = "BENCHMARK"
+TEST_CLASS = "KERNEL"
+TEST_TYPE = "CLIENT"
+DOC = """
+README for lmbench 2alpha8 net release.
+
+To run the benchmark, you should be able to say:
+
+        cd src
+        make results
+
+If you want to see how you did compared to the other system results
+included here, say
+
+        make see
+
+Be warned that many of these benchmarks are sensitive to other things
+being run on the system, mainly from CPU cache and CPU cycle effects.
+So make sure your screen saver is not running, etc.
+
+It's a good idea to do several runs and compare the output like so
+
+        make results
+        make rerun
+        make rerun
+        make rerun
+        cd Results && make LIST=<your OS>/*
+"""
+
 job.run_test('lmbench')

lsb_dtk/control

@@ -1,3 +1,13 @@
+NAME = "LSB-DTK"
+AUTHOR = "Pavan Naregundi <[email protected]>"
+TIME = "MEDIUM"
+TEST_CATEGORY = "FUNCTIONAL"
+TEST_CLASS = "KERNEL"
+TEST_TYPE = "CLIENT"
+DOC = """
+Test for LSB-DTK
+"""
+
 lsb_cfg = '''
 [lsb]
 tarball_url = http://ftp.freestandards.org/pub/lsb/bundles/released-3.1.1/dist-testkit/lsb-dist-testkit-3.1.1-5.%s.tar.gz

ltp/control

@@ -1 +1,11 @@
+NAME = "LTP"
+AUTHOR = "Martin Bligh <[email protected]>"
+TIME = "MEDIUM"
+TEST_CATEGORY = "FUNCTIONAL"
+TEST_CLASS = "KERNEL"
+TEST_TYPE = "CLIENT"
+DOC = """
+Linux Test Project. See http://ltp.sourceforge.net/
+"""
+
 job.run_test('ltp')

ltp/control.ballista

@@ -1 +1,11 @@
+NAME = "LTP (Ballista)"
+AUTHOR = "Martin Bligh <[email protected]>"
+TIME = "MEDIUM"
+TEST_CATEGORY = "FUNCTIONAL"
+TEST_CLASS = "KERNEL"
+TEST_TYPE = "CLIENT"
+DOC = """
+Linux Test Project. See http://ltp.sourceforge.net/
+"""
+
 job.run_test('ltp', '-f ballista')

netperf2/control.client

@@ -1 +1,12 @@
+NAME = "Netperf2 (Client)"
+AUTHOR = "Martin Bligh <[email protected]>"
+TIME = "MEDIUM"
+TEST_CATEGORY = "BENCHMARK"
+TEST_CLASS = "HARDWARE"
+TEST_TYPE = "CLIENT"
+DOC = """
+TCP/UDP/sockets/etc performance benchmark.
+See http://www.netperf.org/netperf/NetperfPage.html.
+"""
+
 job.run_test('netperf2', '10.10.1.2', '10.10.1.6', 'client', tag='client')

netperf2/control.parallel

@@ -1,3 +1,14 @@
+NAME = "Netperf2 (Parallel)"
+AUTHOR = "Martin Bligh <[email protected]>"
+TIME = "MEDIUM"
+TEST_CATEGORY = "BENCHMARK"
+TEST_CLASS = "HARDWARE"
+TEST_TYPE = "CLIENT"
+DOC = """
+TCP/UDP/sockets/etc performance benchmark.
+See http://www.netperf.org/netperf/NetperfPage.html.
+"""
+
 def client():
     job.run_test('netperf2', '127.0.0.1', '127.0.0.1', 'client', tag='client')
 

netperf2/control.server

@@ -1 +1,12 @@
+NAME = "Netperf2 (Server)"
+AUTHOR = "Martin Bligh <[email protected]>"
+TIME = "MEDIUM"
+TEST_CATEGORY = "BENCHMARK"
+TEST_CLASS = "HARDWARE"
+TEST_TYPE = "CLIENT"
+DOC = """
+TCP/UDP/sockets/etc performance benchmark.
+See http://www.netperf.org/netperf/NetperfPage.html.
+"""
+
 job.run_test('netperf2', '10.10.1.2', '10.10.1.6', 'server', tag='server')

parallel_dd/control

@@ -1,3 +1,14 @@
+NAME = "Parallel DD"
+AUTHOR = "Martin Bligh <[email protected]>"
+TIME = "MEDIUM"
+TEST_CATEGORY = "PERFORMANCE"
+TEST_CLASS = "HARDWARE"
+TEST_TYPE = "CLIENT"
+DOC = """
+Measures the performance of writing and reading multiple streams of files onto
+the files system.
+"""
+
 # YOU NEED TO SPECIFY A FILESYSTEM 
 # fs = job.filesystem('/dev/sda3', job.tmpdir)
 job.run_test('parallel_dd', fs, fstype='ext2', iterations=5, megabytes=1000, streams=2)

pi_tests/control

@@ -1 +1,23 @@
+NAME = "Priority inversion tests"
+AUTHOR = "Michal Piotrowski <[email protected]>"
+TIME = "SHORT"
+TEST_CATEGORY = "FUNCTIONAL"
+TEST_CLASS = "KERNEL"
+TEST_TYPE = "CLIENT"
+DOC = """
+The basic premise here is to set up a deadlock scenario and confirm that PI
+mutexes resolve the situation. Three worker threads will be created from the
+main thread: low, medium and high priority threads that use SCHED_FIFO as
+their scheduling policy. The low priority thread claims a mutex and then
+starts "working". The medium priority thread starts and preempts the low
+priority thread. Then the high priority thread runs and attempts to claim
+the mutex owned by the low priority thread. Without priority inheritance,
+this will deadlock the program. With priority inheritance, the low priority
+thread receives a priority boost, finishes it's "work" and releases the mutex,
+which allows the high priority thread to run and finish and then the medium
+priority thread finishes.
+
+That's the theory, anyway...
+"""
+
 job.run_test('pi_tests')