forked from jk-ozlabs/spufs-testsuite
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
156 lines (106 loc) · 5.11 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
spufs-testsuite - tests for the Linux SPU filesystem code
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
See the COPYING file for the full text of the GNU General Public License.
Running:
* bin/run-tests
- to run all tests
* bin/run-tests <test-dir>
- run all tests in <test-dir>
* bin/run-tests <test-file>
- run a single test file
* The -c option will cause the test suite to continue on failures
Building:
* make
* If you have libspe installed in a non-standard location (I use
/home/jk/install/), then add a prefix= argument to make:
make prefix=/home/jk/install
this will update CFLAGS and LDFLAGS appropriately.
Writing tests:
* The test script looks for executables in the test/ directory that
have a name that starts with a number.
* Tests are run in order of their name.
* In its most basic format, we expect a return code of 0
* You can add a test.conf to the test directory to define additional behaviour
The format of this file is:
<test-name>: <options>
where options may be one or more of:
expected_rc=<rc> # expect a rc of <rc> instead of 0
signal=<signum> # expect the test be be killed by <signum>
disabled # disable the test
you can also make tests conditionally run if various capabilities are
available on the system at run-time. These are specicied by cap_* options.
At present, we have the following capabilities:
cap_root # run the test if uid==0
cap_affinity # run the test only on affinity-enabled hardware
Capabilities can be inverted, using the '!' character. For example,
the option "!cap_root" will run the test only if uid!=0.
for example, from the testsuite's own test.conf:
01-fail: expected_rc=1
02-root: cap_root
03-skip: disabled
06-cap: cap_never
07-nocap: !cap_always
08-signal: signal=15
If a test is not listed in test.conf (or there is no test.conf), then
the default options will be used.
* Tests are run in a separate working directory, and have the test's build
directory in the PATH. If you need to create files, use the current working
directory.
* Each test should test the smallest amount of functionality as possible. Since
the tests are run in order, you can assume that all previously-tested
functionality is working.
* If you need to do tricky stuff in your test (eg checking for particular
output), use a shell (or python) script to launch your test and do the
necessary checking. Remember that only executables that start with numbers
are included in the test, so you can include utility programs that don't
start with a number.
Makefiles:
* .. should be kept very simple. If you need a hand, just ask me.
* If you add a test that needs to be compiled, add it to the
Makefile in the same directory, in the 'tests' variable:
tests += 00-pass 01-fail 02-root 03-skip
The test will then be compiled using make's implicit rules. If your
test binary needs more than one .c file, use another target:
tests += sched_multiple
sched_multiple: sched_multiple.o sched_multiple.spe-embed.o
* If you add a directory, add it to tests/Makefile, in the 'dirs' variable"
dirs = 00-testsuite 01-context 02-gang
The directory will need (at least) a Makefile, and hopefully some tests :)
* Your makefile will be included by tests/Makefile.lib, and not executed
directly.
* If you need different compiler arguments, set (or better, append to) the
CFLAGS, CPPFLAGS and LDFLAGS variables.
* If you need to compile with LIBSPE2, the LIBSPE2_CFLAGS and LIBSPE2_LDFLAGS
variables are provided for convenience. Just do this:
CFLAGS += $(LIBSPE2_CFLAGS)
LDFLAGS += $(LIBSPE2_LDFLAGS)
The same applies to libspe1.
* Use implicit make rules wherever possible. This means that the standard
variables (CC, CFLAGS, etc) will be used.
* To build an embeddable spe binary, use an spe-embed.o target. This will
create a dependency on a spe app (foo.spe-embed.o depends on foo.spe), and
build it into an object file, with a symbol called 'foo_spe_app'.
General:
* These tests are intended as a quick, but comprehensive method of verifying
new changes to spufs and/or libspe. The tests should run quickly and with
the absolute minimum of fuss.
* New tests may assume that the following is present:
- gcc
- spu-gcc
- embedspu
- libspe2 (and the libspe1 compat layer)
- bash
- python
* Under no circumstances should your test require odd things outside the
testsuite package. The tests will need to be trivial to get working. If you
need to add dependencies that will be used for multiple tests, add to the
top-level lib/ directory.
* Do not make assumptions about the name or directory of your tests - we may
move tests around as necessary (ie, if we need to add tests that are run
before it).
* Having said that, new tests are absolutely welcome. If you need help with
the testing infrastructure, I'm happy to help. Just email me: [email protected]
Happy testing!