tjh.dev
Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
ktest: Add useful example configs
I've been asked several times to provide more useful example configs for
ktest.pl, as the sample.conf is too complex (because it explains all
configs). This adds configs broken up by use case, and these configs are
based on actual configs that I use on a daily basis.
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
authored by
Steven Rostedt
and committed by
Steven Rostedt
6d76f469
43de3316
+517
+90
tools/testing/ktest/examples/include/bisect.conf
+90
tools/testing/ktest/examples/include/bisect.conf
···
1
+
#
2
+
# This example shows the bisect tests (git bisect and config bisect)
3
+
#
4
+
5
+
6
+
# The config that includes this file may define a RUN_TEST
7
+
# variable that will tell this config what test to run.
8
+
# (what to set the TEST option to).
9
+
#
10
+
DEFAULTS IF NOT DEFINED RUN_TEST
11
+
# Requires that hackbench is in the PATH
12
+
RUN_TEST := ${SSH} hackbench 50
13
+
14
+
15
+
# Set TEST to 'bisect' to do a normal git bisect. You need
16
+
# to modify the options below to make it bisect the exact
17
+
# commits you are interested in.
18
+
#
19
+
TEST_START IF ${TEST} == bisect
20
+
TEST_TYPE = bisect
21
+
# You must set the commit that was considered good (git bisect good)
22
+
BISECT_GOOD = v3.3
23
+
# You must set the commit that was considered bad (git bisect bad)
24
+
BISECT_BAD = HEAD
25
+
# It's best to specify the branch to checkout before starting the bisect.
26
+
CHECKOUT = origin/master
27
+
# This can be build, boot, or test. Here we are doing a bisect
28
+
# that requires to run a test to know if the bisect was good or bad.
29
+
# The test should exit with 0 on good, non-zero for bad. But see
30
+
# the BISECT_RET_* options in samples.conf to override this.
31
+
BISECT_TYPE = test
32
+
TEST = ${RUN_TEST}
33
+
# It is usually a good idea to confirm that the GOOD and the BAD
34
+
# commits are truly good and bad respectively. Having BISECT_CHECK
35
+
# set to 1 will check both that the good commit works and the bad
36
+
# commit fails. If you only want to check one or the other,
37
+
# set BISECT_CHECK to 'good' or to 'bad'.
38
+
BISECT_CHECK = 1
39
+
#BISECT_CHECK = good
40
+
#BISECT_CHECK = bad
41
+
42
+
# Usually it's a good idea to specify the exact config you
43
+
# want to use throughout the entire bisect. Here we placed
44
+
# it in the directory we called ktest.pl from and named it
45
+
# 'config-bisect'.
46
+
MIN_CONFIG = ${THIS_DIR}/config-bisect
47
+
# By default, if we are doing a BISECT_TYPE = test run but the
48
+
# build or boot fails, ktest.pl will do a 'git bisect skip'.
49
+
# Uncomment the below option to make ktest stop testing on such
50
+
# an error.
51
+
#BISECT_SKIP = 0
52
+
# Now if you had BISECT_SKIP = 0 and the test fails, you can
53
+
# examine what happened and then do 'git bisect log > /tmp/replay'
54
+
# Set BISECT_REPLAY to /tmp/replay and ktest.pl will run the
55
+
# 'git bisect replay /tmp/replay' before continuing the bisect test.
56
+
#BISECT_REPLAY = /tmp/replay
57
+
# If you used BISECT_REPLAY after the bisect test failed, you may
58
+
# not want to continue the bisect on that commit that failed.
59
+
# By setting BISECT_START to a new commit. ktest.pl will checkout
60
+
# that commit after it has performed the 'git bisect replay' but
61
+
# before it continues running the bisect test.
62
+
#BISECT_START = 2545eb6198e7e1ec50daa0cfc64a4cdfecf24ec9
63
+
64
+
# Now if you don't trust ktest.pl to make the decisions for you, then
65
+
# set BISECT_MANUAL to 1. This will cause ktest.pl not to decide
66
+
# if the commit was good or bad. Instead, it will ask you to tell
67
+
# it if the current commit was good. In the mean time, you could
68
+
# take the result, load it on any machine you want. Run several tests,
69
+
# or whatever you feel like. Then, when you are happy, you can tell
70
+
# ktest if you think it was good or not and ktest.pl will continue
71
+
# the git bisect. You can even change what commit it is currently at.
72
+
#BISECT_MANUAL = 1
73
+
74
+
75
+
# One of the unique tests that ktest does is the config bisect.
76
+
# Currently (which hopefully will be fixed soon), the bad config
77
+
# must be a superset of the good config. This is because it only
78
+
# searches for a config that causes the target to fail. If the
79
+
# good config is not a subset of the bad config, or if the target
80
+
# fails because of a lack of a config, then it will not find
81
+
# the config for you.
82
+
TEST_START IF ${TEST} == config-bisect
83
+
TEST_TYPE = config_bisect
84
+
# set to build, boot, test
85
+
CONFIG_BISECT_TYPE = boot
86
+
# Set the config that is considered bad.
87
+
CONFIG_BISECT = ${THIS_DIR}/config-bad
88
+
# This config is optional. By default it uses the
89
+
# MIN_CONFIG as the good config.
90
+
CONFIG_BISECT_GOOD = ${THIS_DIR}/config-good
+157
tools/testing/ktest/examples/include/defaults.conf
+157
tools/testing/ktest/examples/include/defaults.conf
···
1
+
# This file holds defaults for most the tests. It defines the options that
2
+
# are most common to tests that are likely to be shared.
3
+
#
4
+
# Note, after including this file, a config file may override any option
5
+
# with a DEFAULTS OVERRIDE section.
6
+
#
7
+
8
+
# For those cases that use the same machine to boot a 64 bit
9
+
# and a 32 bit version. The MACHINE is the DNS name to get to the
10
+
# box (usually different if it was 64 bit or 32 bit) but the
11
+
# BOX here is defined as a variable that will be the name of the box
12
+
# itself. It is useful for calling scripts that will power cycle
13
+
# the box, as only one script needs to be created to power cycle
14
+
# even though the box itself has multiple operating systems on it.
15
+
# By default, BOX and MACHINE are the same.
16
+
17
+
DEFAULTS IF NOT DEFINED BOX
18
+
BOX := ${MACHINE}
19
+
20
+
21
+
# Consider each box as 64 bit box, unless the config including this file
22
+
# has defined BITS = 32
23
+
24
+
DEFAULTS IF NOT DEFINED BITS
25
+
BITS := 64
26
+
27
+
28
+
DEFAULTS
29
+
30
+
# THIS_DIR is used through out the configs and defaults to ${PWD} which
31
+
# is the directory that ktest.pl was called from.
32
+
33
+
THIS_DIR := ${PWD}
34
+
35
+
36
+
# to orginize your configs, having each machine save their configs
37
+
# into a separate directly is useful.
38
+
CONFIG_DIR := ${THIS_DIR}/configs/${MACHINE}
39
+
40
+
# Reset the log before running each test.
41
+
CLEAR_LOG = 1
42
+
43
+
# As installing kernels usually requires root privilege, default the
44
+
# user on the target as root. It is also required that the target
45
+
# allows ssh to root from the host without asking for a password.
46
+
47
+
SSH_USER = root
48
+
49
+
# For accesing the machine, we will ssh to root@machine.
50
+
SSH := ssh ${SSH_USER}@${MACHINE}
51
+
52
+
# Update this. The default here is ktest will ssh to the target box
53
+
# and run a script called 'run-test' located on that box.
54
+
TEST = ${SSH} run-test
55
+
56
+
# Point build dir to the git repo you use
57
+
BUILD_DIR = ${THIS_DIR}/linux.git
58
+
59
+
# Each machine will have its own output build directory.
60
+
OUTPUT_DIR = ${THIS_DIR}/build/${MACHINE}
61
+
62
+
# Yes this config is focused on x86 (but ktest works for other archs too)
63
+
BUILD_TARGET = arch/x86/boot/bzImage
64
+
TARGET_IMAGE = /boot/vmlinuz-test
65
+
66
+
# have directory for the scripts to reboot and power cycle the boxes
67
+
SCRIPTS_DIR := ${THIS_DIR}/scripts
68
+
69
+
# You can have each box/machine have a script to power cycle it.
70
+
# Name your script <box>-cycle.
71
+
POWER_CYCLE = ${SCRIPTS_DIR}/${BOX}-cycle
72
+
73
+
# This script is used to power off the box.
74
+
POWER_OFF = ${SCRIPTS_DIR}/${BOX}-poweroff
75
+
76
+
# Keep your test kernels separate from your other kernels.
77
+
LOCALVERSION = -test
78
+
79
+
# The /boot/grub/menu.lst is searched for the line:
80
+
# title Test Kernel
81
+
# and ktest will use that kernel to reboot into.
82
+
# For grub2 or other boot loaders, you need to set BOOT_TYPE
83
+
# to 'script' and define other ways to load the kernel.
84
+
# See snowball.conf example.
85
+
#
86
+
GRUB_MENU = Test Kernel
87
+
88
+
# The kernel build will use this option.
89
+
BUILD_OPTIONS = -j8
90
+
91
+
# Keeping the log file with the output dir is convenient.
92
+
LOG_FILE = ${OUTPUT_DIR}/${MACHINE}.log
93
+
94
+
# Each box should have their own minum configuration
95
+
# See min-config.conf
96
+
MIN_CONFIG = ${CONFIG_DIR}/config-min
97
+
98
+
# For things like randconfigs, there may be configs you find that
99
+
# are already broken, or there may be some configs that you always
100
+
# want set. Uncomment ADD_CONFIG and point it to the make config files
101
+
# that set the configs you want to keep on (or off) in your build.
102
+
# ADD_CONFIG is usually something to add configs to all machines,
103
+
# where as, MIN_CONFIG is specific per machine.
104
+
#ADD_CONFIG = ${THIS_DIR}/config-broken ${THIS_DIR}/config-general
105
+
106
+
# To speed up reboots for bisects and patchcheck, instead of
107
+
# waiting 60 seconds for the console to be idle, if this line is
108
+
# seen in the console output, ktest will know the good kernel has
109
+
# finished rebooting and it will be able to continue the tests.
110
+
REBOOT_SUCCESS_LINE = ${MACHINE} login:
111
+
112
+
# The following is different ways to end the test.
113
+
# by setting the variable REBOOT to: none, error, fail or
114
+
# something else, ktest will power cycle or reboot the target box
115
+
# at the end of the tests.
116
+
#
117
+
# REBOOT := none
118
+
# Don't do anything at the end of the test.
119
+
#
120
+
# REBOOT := error
121
+
# Reboot the box if ktest detects an error
122
+
#
123
+
# REBOOT := fail
124
+
# Do not stop on failure, and after all tests are complete
125
+
# power off the box (for both success and error)
126
+
# This is good to run over a weekend and you don't want to waste
127
+
# electricity.
128
+
#
129
+
130
+
DEFAULTS IF ${REBOOT} == none
131
+
REBOOT_ON_SUCCESS = 0
132
+
REBOOT_ON_ERROR = 0
133
+
POWEROFF_ON_ERROR = 0
134
+
POWEROFF_ON_SUCCESS = 0
135
+
136
+
DEFAULTS ELSE IF ${REBOOT} == error
137
+
REBOOT_ON_SUCCESS = 0
138
+
REBOOT_ON_ERROR = 1
139
+
POWEROFF_ON_ERROR = 0
140
+
POWEROFF_ON_SUCCESS = 0
141
+
142
+
DEFAULTS ELSE IF ${REBOOT} == fail
143
+
REBOOT_ON_SUCCESS = 0
144
+
POWEROFF_ON_ERROR = 1
145
+
POWEROFF_ON_SUCCESS = 1
146
+
POWEROFF_AFTER_HALT = 120
147
+
DIE_ON_FAILURE = 0
148
+
149
+
# Store the failure information into this directory
150
+
# such as the .config, dmesg, and build log.
151
+
STORE_FAILURES = ${THIS_DIR}/failures
152
+
153
+
DEFAULTS ELSE
154
+
REBOOT_ON_SUCCESS = 1
155
+
REBOOT_ON_ERROR = 1
156
+
POWEROFF_ON_ERROR = 0
157
+
POWEROFF_ON_SUCCESS = 0
+60
tools/testing/ktest/examples/include/min-config.conf
+60
tools/testing/ktest/examples/include/min-config.conf
···
1
+
#
2
+
# This file has some examples for creating a MIN_CONFIG.
3
+
# (A .config file that is the minimum for a machine to boot, or
4
+
# to boot and make a network connection.)
5
+
#
6
+
# A MIN_CONFIG is very useful as it is the minimum configuration
7
+
# needed to boot a given machine. You can debug someone else's
8
+
# .config by only setting the configs in your MIN_CONFIG. The closer
9
+
# your MIN_CONFIG is to the true minimum set of configs needed to
10
+
# boot your machine, the closer the config you test with will be
11
+
# to the users config that had the failure.
12
+
#
13
+
# The make_min_config test allows you to create a MIN_CONFIG that
14
+
# is truly the minimum set of configs needed to boot a box.
15
+
#
16
+
# In this example, the final config will reside in
17
+
# ${CONFIG_DIR}/config-new-min and ${CONFIG_DIR}/config-new-min-net.
18
+
# Just move one to the location you have set for MIN_CONFIG.
19
+
#
20
+
# The first test creates a MIN_CONFIG that will be the minimum
21
+
# configuration to boot ${MACHINE} and be able to ssh to it.
22
+
#
23
+
# The second test creates a MIN_CONFIG that will only boot
24
+
# the target and most likely will not let you ssh to it. (Notice
25
+
# how the second test uses the first test's result to continue with.
26
+
# This is because the second test config is a subset of the first).
27
+
#
28
+
# The ${CONFIG_DIR}/config-skip (and -net) will hold the configs
29
+
# that ktest.pl found would not boot the target without them set.
30
+
# The config-new-min holds configs that ktest.pl could not test
31
+
# directly because another config that was needed to boot the box
32
+
# selected them. Sometimes it is possible that this file will hold
33
+
# the true minimum configuration. You can test to see if this is
34
+
# the case by running the boot test with BOOT_TYPE = allnoconfig and
35
+
# setting setting the MIN_CONFIG to ${CONFIG_DIR}/config-skip. If the
36
+
# machine still boots, then you can use the config-skip as your MIN_CONFIG.
37
+
#
38
+
# These tests can run for several hours (and perhaps days).
39
+
# It's OK to kill the test with a Ctrl^C. By restarting without
40
+
# modifying this config, ktest.pl will notice that the config-new-min(-net)
41
+
# exists, and will use that instead as the starting point.
42
+
# The USE_OUTPUT_MIN_CONFIG is set to 1 to keep ktest.pl from asking
43
+
# you if you want to use the OUTPUT_MIN_CONFIG as the starting point.
44
+
# By using the OUTPUT_MIN_CONFIG as the starting point will allow ktest.pl to
45
+
# start almost where it left off.
46
+
#
47
+
TEST_START IF ${TEST} == min-config
48
+
TEST_TYPE = make_min_config
49
+
OUTPUT_MIN_CONFIG = ${CONFIG_DIR}/config-new-min-net
50
+
IGNORE_CONFIG = ${CONFIG_DIR}/config-skip-net
51
+
MIN_CONFIG_TYPE = test
52
+
TEST = ${SSH} echo hi
53
+
USE_OUTPUT_MIN_CONFIG = 1
54
+
55
+
TEST_START IF ${TEST} == min-config && ${MULTI}
56
+
TEST_TYPE = make_min_config
57
+
OUTPUT_MIN_CONFIG = ${CONFIG_DIR}/config-new-min
58
+
IGNORE_CONFIG = ${CONFIG_DIR}/config-skip
59
+
MIN_CONFIG = ${CONFIG_DIR}/config-new-min-net
60
+
USE_OUTPUT_MIN_CONFIG = 1
+74
tools/testing/ktest/examples/include/patchcheck.conf
+74
tools/testing/ktest/examples/include/patchcheck.conf
···
1
+
# patchcheck.conf
2
+
#
3
+
# This contains a test that takes two git commits and will test each
4
+
# commit between the two. The build test will look at what files the
5
+
# commit has touched, and if any of those files produce a warning, then
6
+
# the build will fail.
7
+
8
+
9
+
# PATCH_START is the commit to begin with and PATCH_END is the commit
10
+
# to end with (inclusive). This is similar to doing a git rebase -i PATCH_START~1
11
+
# and then testing each commit and doing a git rebase --continue.
12
+
# You can use a SHA1, a git tag, or anything that git will accept for a checkout
13
+
14
+
PATCH_START := HEAD~3
15
+
PATCH_END := HEAD
16
+
17
+
# Change PATCH_CHECKOUT to be the branch you want to test. The test will
18
+
# do a git checkout of this branch before starting. Obviously both
19
+
# PATCH_START and PATCH_END must be in this branch (and PATCH_START must
20
+
# be contained by PATCH_END).
21
+
22
+
PATCH_CHECKOUT := test/branch
23
+
24
+
# Usually it's a good idea to have a set config to use for testing individual
25
+
# patches.
26
+
PATCH_CONFIG := ${CONFIG_DIR}/config-patchcheck
27
+
28
+
# Change PATCH_TEST to run some test for each patch. Each commit that is
29
+
# tested, after it is built and installed on the test machine, this command
30
+
# will be executed. Usually what is done is to ssh to the target box and
31
+
# run some test scripts. If you just want to boot test your patches
32
+
# comment PATCH_TEST out.
33
+
PATCH_TEST := ${SSH} "/usr/local/bin/ktest-test-script"
34
+
35
+
DEFAULTS IF DEFINED PATCH_TEST
36
+
PATCH_TEST_TYPE := test
37
+
38
+
DEFAULTS ELSE
39
+
PATCH_TEST_TYPE := boot
40
+
41
+
# If for some reason a file has a warning that one of your patches touch
42
+
# but you do not care about it, set IGNORE_WARNINGS to that commit(s)
43
+
# (space delimited)
44
+
#IGNORE_WARNINGS = 39eaf7ef884dcc44f7ff1bac803ca2a1dcf43544 6edb2a8a385f0cdef51dae37ff23e74d76d8a6ce
45
+
46
+
# If you are running a multi test, and the test failed on the first
47
+
# test but on, say the 5th patch. If you want to restart on the
48
+
# fifth patch, set PATCH_START1. This will make the first test start
49
+
# from this commit instead of the PATCH_START commit.
50
+
# Note, do not change this option. Just define PATCH_START1 in the
51
+
# top config (the one you pass to ktest.pl), and this will use it,
52
+
# otherwise it will just use PATCH_START if PATCH_START1 is not defined.
53
+
DEFAULTS IF NOT DEFINED PATCH_START1
54
+
PATCH_START1 := ${PATCH_START}
55
+
56
+
TEST_START IF ${TEST} == patchcheck
57
+
TEST_TYPE = patchcheck
58
+
MIN_CONFIG = ${PATCH_CONFIG}
59
+
TEST = ${PATCH_TEST}
60
+
PATCHCHECK_TYPE = ${PATCH_TEST_TYPE}
61
+
PATCHCHECK_START = ${PATCH_START1}
62
+
PATCHCHECK_END = ${PATCH_END}
63
+
CHECKOUT = ${PATCH_CHECKOUT}
64
+
65
+
TEST_START IF ${TEST} == patchcheck && ${MULTI}
66
+
TEST_TYPE = patchcheck
67
+
MIN_CONFIG = ${PATCH_CONFIG}
68
+
TEST = ${PATCH_TEST}
69
+
PATCHCHECK_TYPE = ${PATCH_TEST_TYPE}
70
+
PATCHCHECK_START = ${PATCH_START}
71
+
PATCHCHECK_END = ${PATCH_END}
72
+
CHECKOUT = ${PATCH_CHECKOUT}
73
+
# Use multi to test different compilers?
74
+
MAKE_CMD = CC=gcc-4.5.1 make
+74
tools/testing/ktest/examples/include/tests.conf
+74
tools/testing/ktest/examples/include/tests.conf
···
1
+
#
2
+
# This is an example of various tests that you can run
3
+
#
4
+
# The variable TEST can be of boot, build, randconfig, or test.
5
+
#
6
+
# Note that TEST is a variable created with ':=' and only exists
7
+
# throughout the config processing (not during the tests itself).
8
+
#
9
+
# The TEST option (defined with '=') is used to tell ktest.pl
10
+
# what test to run after a successful boot. The TEST option is
11
+
# persistent into the test runs.
12
+
#
13
+
14
+
# The config that includes this file may define a BOOT_TYPE
15
+
# variable that tells this config what type of boot test to run.
16
+
# If it's not defined, the below DEFAULTS will set the default
17
+
# to 'oldconfig'.
18
+
#
19
+
DEFAULTS IF NOT DEFINED BOOT_TYPE
20
+
BOOT_TYPE := oldconfig
21
+
22
+
# The config that includes this file may define a RUN_TEST
23
+
# variable that will tell this config what test to run.
24
+
# (what to set the TEST option to).
25
+
#
26
+
DEFAULTS IF NOT DEFINED RUN_TEST
27
+
# Requires that hackbench is in the PATH
28
+
RUN_TEST := ${SSH} hackbench 50
29
+
30
+
31
+
# If TEST is set to 'boot' then just build a kernel and boot
32
+
# the target.
33
+
TEST_START IF ${TEST} == boot
34
+
TEST_TYPE = boot
35
+
# Notice how we set the BUILD_TYPE option to the BOOT_TYPE variable.
36
+
BUILD_TYPE = ${BOOT_TYPE}
37
+
# Do not do a make mrproper.
38
+
BUILD_NOCLEAN = 1
39
+
40
+
# If you only want to build the kernel, and perhaps install
41
+
# and test it yourself, then just set TEST to build.
42
+
TEST_START IF ${TEST} == build
43
+
TEST_TYPE = build
44
+
BUILD_TYPE = ${BOOT_TYPE}
45
+
BUILD_NOCLEAN = 1
46
+
47
+
# Build, install, boot and test with a randconfg 10 times.
48
+
# It is important that you have set MIN_CONFIG in the config
49
+
# that includes this file otherwise it is likely that the
50
+
# randconfig will not have the neccessary configs needed to
51
+
# boot your box. This version of the test requires a min
52
+
# config that has enough to make sure the target has network
53
+
# working.
54
+
TEST_START ITERATE 10 IF ${TEST} == randconfig
55
+
MIN_CONFIG = ${CONFIG_DIR}/config-min-net
56
+
TEST_TYPE = test
57
+
BUILD_TYPE = randconfig
58
+
TEST = ${RUN_TEST}
59
+
60
+
# This is the same as above, but only tests to a boot prompt.
61
+
# The MIN_CONFIG used here does not need to have networking
62
+
# working.
63
+
TEST_START ITERATE 10 IF ${TEST} == randconfig && ${MULTI}
64
+
TEST_TYPE = boot
65
+
BUILD_TYPE = randconfig
66
+
MIN_CONFIG = ${CONFIG_DIR}/config-min
67
+
MAKE_CMD = make
68
+
69
+
# This builds, installs, boots and tests the target.
70
+
TEST_START IF ${TEST} == test
71
+
TEST_TYPE = test
72
+
BUILD_TYPE = ${BOOT_TYPE}
73
+
TEST = ${RUN_TEST}
74
+
BUILD_NOCLEAN = 1
+62
tools/testing/ktest/examples/test.conf
+62
tools/testing/ktest/examples/test.conf
···
1
+
#
2
+
# Generic config for a machine
3
+
#
4
+
5
+
# Name your machine (the DNS name, what you ssh to)
6
+
MACHINE = foo
7
+
8
+
# BOX can be different than foo, if the machine BOX has
9
+
# multiple partitions with different systems installed. For example,
10
+
# you may have a i386 and x86_64 installation on a test box.
11
+
# If this is the case, MACHINE defines the way to connect to the
12
+
# machine, which may be different between which system the machine
13
+
# is booting into. BOX is used for the scripts to reboot and power cycle
14
+
# the machine, where it does not matter which system the machine boots into.
15
+
#
16
+
#BOX := bar
17
+
18
+
# Define a way to read the console
19
+
CONSOLE = stty -F /dev/ttyS0 115200 parodd; cat /dev/ttyS0
20
+
21
+
# The include files will set up the type of test to run. Just set TEST to
22
+
# which test you want to run.
23
+
#
24
+
# TESTS = patchcheck, randconfig, boot, test, config-bisect, bisect, min-config
25
+
#
26
+
# See the include/*.conf files that define these tests
27
+
#
28
+
TEST := patchcheck
29
+
30
+
# Some tests may have more than one test to run. Define MULTI := 1 to run
31
+
# the extra tests.
32
+
MULTI := 0
33
+
34
+
# In case you want to differentiate which type of system you are testing
35
+
BITS := 64
36
+
37
+
# REBOOT = none, error, fail, empty
38
+
# See include/defaults.conf
39
+
REBOOT := empty
40
+
41
+
# The defaults file will set up various settings that can be used by all
42
+
# machine configs.
43
+
INCLUDE include/defaults.conf
44
+
45
+
# In case you need to add a patch for a bisect or something
46
+
#PRE_BUILD = patch -p1 < ${THIS_DIR}/fix.patch
47
+
48
+
# Reset the repo after the build and remove all 'test' modules from the target
49
+
# Notice that DO_POST_BUILD is a variable (defined by ':=') and POST_BUILD
50
+
# is the option (defined by '=')
51
+
52
+
DO_POST_BUILD := git reset --hard
53
+
POST_BUILD = ${SSH} 'rm -rf /lib/modules/*-test*'; ${DO_POST_BUILD}
54
+
55
+
# The following files each handle a different test case.
56
+
# Having them included allows you to set up more than one machine and share
57
+
# the same tests.
58
+
INCLUDE include/patchcheck.conf
59
+
INCLUDE include/tests.conf
60
+
INCLUDE include/bisect.conf
61
+
INCLUDE include/min-config.conf
62
+