ktest: Add useful example configs

#

# This example shows the bisect tests (git bisect and config bisect)

#

# The config that includes this file may define a RUN_TEST

# variable that will tell this config what test to run.

# (what to set the TEST option to).

#

DEFAULTS IF NOT DEFINED RUN_TEST

# Requires that hackbench is in the PATH

RUN_TEST := ${SSH} hackbench 50

# Set TEST to 'bisect' to do a normal git bisect. You need

# to modify the options below to make it bisect the exact

# commits you are interested in.

#

TEST_START IF ${TEST} == bisect

TEST_TYPE = bisect

# You must set the commit that was considered good (git bisect good)

BISECT_GOOD = v3.3

# You must set the commit that was considered bad (git bisect bad)

BISECT_BAD = HEAD

# It's best to specify the branch to checkout before starting the bisect.

CHECKOUT = origin/master

# This can be build, boot, or test. Here we are doing a bisect

# that requires to run a test to know if the bisect was good or bad.

# The test should exit with 0 on good, non-zero for bad. But see

# the BISECT_RET_* options in samples.conf to override this.

BISECT_TYPE = test

TEST = ${RUN_TEST}

# It is usually a good idea to confirm that the GOOD and the BAD

# commits are truly good and bad respectively. Having BISECT_CHECK

# set to 1 will check both that the good commit works and the bad

# commit fails. If you only want to check one or the other,

# set BISECT_CHECK to 'good' or to 'bad'.

BISECT_CHECK = 1

#BISECT_CHECK = good

#BISECT_CHECK = bad

# Usually it's a good idea to specify the exact config you

# want to use throughout the entire bisect. Here we placed

# it in the directory we called ktest.pl from and named it

# 'config-bisect'.

MIN_CONFIG = ${THIS_DIR}/config-bisect

# By default, if we are doing a BISECT_TYPE = test run but the

# build or boot fails, ktest.pl will do a 'git bisect skip'.

# Uncomment the below option to make ktest stop testing on such

# an error.

#BISECT_SKIP = 0

# Now if you had BISECT_SKIP = 0 and the test fails, you can

# examine what happened and then do 'git bisect log > /tmp/replay'

# Set BISECT_REPLAY to /tmp/replay and ktest.pl will run the

# 'git bisect replay /tmp/replay' before continuing the bisect test.

#BISECT_REPLAY = /tmp/replay

# If you used BISECT_REPLAY after the bisect test failed, you may

# not want to continue the bisect on that commit that failed.

# By setting BISECT_START to a new commit. ktest.pl will checkout

# that commit after it has performed the 'git bisect replay' but

# before it continues running the bisect test.

#BISECT_START = 2545eb6198e7e1ec50daa0cfc64a4cdfecf24ec9

# Now if you don't trust ktest.pl to make the decisions for you, then

# set BISECT_MANUAL to 1. This will cause ktest.pl not to decide

# if the commit was good or bad. Instead, it will ask you to tell

# it if the current commit was good. In the mean time, you could

# take the result, load it on any machine you want. Run several tests,

# or whatever you feel like. Then, when you are happy, you can tell

# ktest if you think it was good or not and ktest.pl will continue

# the git bisect. You can even change what commit it is currently at.

#BISECT_MANUAL = 1

# One of the unique tests that ktest does is the config bisect.

# Currently (which hopefully will be fixed soon), the bad config

# must be a superset of the good config. This is because it only

# searches for a config that causes the target to fail. If the

# good config is not a subset of the bad config, or if the target

# fails because of a lack of a config, then it will not find

# the config for you.

TEST_START IF ${TEST} == config-bisect

TEST_TYPE = config_bisect

# set to build, boot, test

CONFIG_BISECT_TYPE = boot

# Set the config that is considered bad.

CONFIG_BISECT = ${THIS_DIR}/config-bad

# This config is optional. By default it uses the

# MIN_CONFIG as the good config.

CONFIG_BISECT_GOOD = ${THIS_DIR}/config-good

# This file holds defaults for most the tests. It defines the options that

# are most common to tests that are likely to be shared.

#

# Note, after including this file, a config file may override any option

# with a DEFAULTS OVERRIDE section.

#

# For those cases that use the same machine to boot a 64 bit

# and a 32 bit version. The MACHINE is the DNS name to get to the

# box (usually different if it was 64 bit or 32 bit) but the

# BOX here is defined as a variable that will be the name of the box

# itself. It is useful for calling scripts that will power cycle

# the box, as only one script needs to be created to power cycle

# even though the box itself has multiple operating systems on it.

# By default, BOX and MACHINE are the same.

DEFAULTS IF NOT DEFINED BOX

BOX := ${MACHINE}

# Consider each box as 64 bit box, unless the config including this file

# has defined BITS = 32

DEFAULTS IF NOT DEFINED BITS

BITS := 64

DEFAULTS

# THIS_DIR is used through out the configs and defaults to ${PWD} which

# is the directory that ktest.pl was called from.

THIS_DIR := ${PWD}

# to orginize your configs, having each machine save their configs

# into a separate directly is useful.

CONFIG_DIR := ${THIS_DIR}/configs/${MACHINE}

# Reset the log before running each test.

CLEAR_LOG = 1

# As installing kernels usually requires root privilege, default the

# user on the target as root. It is also required that the target

# allows ssh to root from the host without asking for a password.

SSH_USER = root

# For accesing the machine, we will ssh to root@machine.

SSH := ssh ${SSH_USER}@${MACHINE}

# Update this. The default here is ktest will ssh to the target box

# and run a script called 'run-test' located on that box.

TEST = ${SSH} run-test

# Point build dir to the git repo you use

BUILD_DIR = ${THIS_DIR}/linux.git

# Each machine will have its own output build directory.

OUTPUT_DIR = ${THIS_DIR}/build/${MACHINE}

# Yes this config is focused on x86 (but ktest works for other archs too)

BUILD_TARGET = arch/x86/boot/bzImage

TARGET_IMAGE = /boot/vmlinuz-test

# have directory for the scripts to reboot and power cycle the boxes

SCRIPTS_DIR := ${THIS_DIR}/scripts

# You can have each box/machine have a script to power cycle it.

# Name your script <box>-cycle.

POWER_CYCLE = ${SCRIPTS_DIR}/${BOX}-cycle

# This script is used to power off the box.

POWER_OFF = ${SCRIPTS_DIR}/${BOX}-poweroff

# Keep your test kernels separate from your other kernels.

LOCALVERSION = -test

# The /boot/grub/menu.lst is searched for the line:

#  title Test Kernel

# and ktest will use that kernel to reboot into.

# For grub2 or other boot loaders, you need to set BOOT_TYPE

# to 'script' and define other ways to load the kernel.

# See snowball.conf example.

#

GRUB_MENU = Test Kernel

# The kernel build will use this option.

BUILD_OPTIONS = -j8

# Keeping the log file with the output dir is convenient.

LOG_FILE = ${OUTPUT_DIR}/${MACHINE}.log

# Each box should have their own minum configuration

# See min-config.conf

MIN_CONFIG = ${CONFIG_DIR}/config-min

# For things like randconfigs, there may be configs you find that

# are already broken, or there may be some configs that you always

# want set. Uncomment ADD_CONFIG and point it to the make config files

# that set the configs you want to keep on (or off) in your build.

# ADD_CONFIG is usually something to add configs to all machines,

# where as, MIN_CONFIG is specific per machine.

#ADD_CONFIG = ${THIS_DIR}/config-broken ${THIS_DIR}/config-general

# To speed up reboots for bisects and patchcheck, instead of

# waiting 60 seconds for the console to be idle, if this line is

# seen in the console output, ktest will know the good kernel has

# finished rebooting and it will be able to continue the tests.

REBOOT_SUCCESS_LINE = ${MACHINE} login:

# The following is different ways to end the test.

# by setting the variable REBOOT to: none, error, fail or

# something else, ktest will power cycle or reboot the target box

# at the end of the tests.

#

# REBOOT := none

#   Don't do anything at the end of the test.

#

# REBOOT := error

#   Reboot the box if ktest detects an error

#

# REBOOT := fail

#   Do not stop on failure, and after all tests are complete

#   power off the box (for both success and error)

#   This is good to run over a weekend and you don't want to waste

#   electricity.

#

DEFAULTS IF ${REBOOT} == none

REBOOT_ON_SUCCESS = 0

REBOOT_ON_ERROR = 0

POWEROFF_ON_ERROR = 0

POWEROFF_ON_SUCCESS = 0

DEFAULTS ELSE IF ${REBOOT} == error

REBOOT_ON_SUCCESS = 0

REBOOT_ON_ERROR = 1

POWEROFF_ON_ERROR = 0

POWEROFF_ON_SUCCESS = 0

DEFAULTS ELSE IF ${REBOOT} == fail

REBOOT_ON_SUCCESS = 0

POWEROFF_ON_ERROR = 1

POWEROFF_ON_SUCCESS = 1

POWEROFF_AFTER_HALT = 120

DIE_ON_FAILURE = 0

# Store the failure information into this directory

# such as the .config, dmesg, and build log.

STORE_FAILURES = ${THIS_DIR}/failures

DEFAULTS ELSE

REBOOT_ON_SUCCESS = 1

REBOOT_ON_ERROR = 1

POWEROFF_ON_ERROR = 0

POWEROFF_ON_SUCCESS = 0

#

# This file has some examples for creating a MIN_CONFIG.

# (A .config file that is the minimum for a machine to boot, or

#  to boot and make a network connection.)

#

# A MIN_CONFIG is very useful as it is the minimum configuration

# needed to boot a given machine. You can debug someone else's

# .config by only setting the configs in your MIN_CONFIG. The closer

# your MIN_CONFIG is to the true minimum set of configs needed to

# boot your machine, the closer the config you test with will be

# to the users config that had the failure.

#

# The make_min_config test allows you to create a MIN_CONFIG that

# is truly the minimum set of configs needed to boot a box.

#

# In this example, the final config will reside in

# ${CONFIG_DIR}/config-new-min and ${CONFIG_DIR}/config-new-min-net.

# Just move one to the location you have set for MIN_CONFIG.

#

# The first test creates a MIN_CONFIG that will be the minimum

# configuration to boot ${MACHINE} and be able to ssh to it.

#

# The second test creates a MIN_CONFIG that will only boot

# the target and most likely will not let you ssh to it. (Notice

# how the second test uses the first test's result to continue with.

# This is because the second test config is a subset of the first).

#

# The ${CONFIG_DIR}/config-skip (and -net) will hold the configs

# that ktest.pl found would not boot the target without them set.

# The config-new-min holds configs that ktest.pl could not test

# directly because another config that was needed to boot the box

# selected them. Sometimes it is possible that this file will hold

# the true minimum configuration. You can test to see if this is

# the case by running the boot test with BOOT_TYPE = allnoconfig and

# setting setting the MIN_CONFIG to ${CONFIG_DIR}/config-skip. If the

# machine still boots, then you can use the config-skip as your MIN_CONFIG.

#

# These tests can run for several hours (and perhaps days).

# It's OK to kill the test with a Ctrl^C. By restarting without

# modifying this config, ktest.pl will notice that the config-new-min(-net)

# exists, and will use that instead as the starting point.

# The USE_OUTPUT_MIN_CONFIG is set to 1 to keep ktest.pl from asking

# you if you want to use the OUTPUT_MIN_CONFIG as the starting point.

# By using the OUTPUT_MIN_CONFIG as the starting point will allow ktest.pl to

# start almost where it left off.

#

TEST_START IF ${TEST} == min-config

TEST_TYPE = make_min_config

OUTPUT_MIN_CONFIG = ${CONFIG_DIR}/config-new-min-net

IGNORE_CONFIG = ${CONFIG_DIR}/config-skip-net

MIN_CONFIG_TYPE = test

TEST = ${SSH} echo hi

USE_OUTPUT_MIN_CONFIG = 1

TEST_START IF ${TEST} == min-config && ${MULTI}

TEST_TYPE = make_min_config

OUTPUT_MIN_CONFIG = ${CONFIG_DIR}/config-new-min

IGNORE_CONFIG = ${CONFIG_DIR}/config-skip

MIN_CONFIG = ${CONFIG_DIR}/config-new-min-net

USE_OUTPUT_MIN_CONFIG = 1

# patchcheck.conf

#

# This contains a test that takes two git commits and will test each

# commit between the two. The build test will look at what files the

# commit has touched, and if any of those files produce a warning, then

# the build will fail.

# PATCH_START is the commit to begin with and PATCH_END is the commit

# to end with (inclusive). This is similar to doing a git rebase -i PATCH_START~1

# and then testing each commit and doing a git rebase --continue.

# You can use a SHA1, a git tag, or anything that git will accept for a checkout

PATCH_START := HEAD~3

PATCH_END := HEAD

# Change PATCH_CHECKOUT to be the branch you want to test. The test will

# do a git checkout of this branch before starting. Obviously both

# PATCH_START and PATCH_END must be in this branch (and PATCH_START must

# be contained by PATCH_END).

PATCH_CHECKOUT := test/branch

# Usually it's a good idea to have a set config to use for testing individual

# patches.

PATCH_CONFIG := ${CONFIG_DIR}/config-patchcheck

# Change PATCH_TEST to run some test for each patch. Each commit that is

# tested, after it is built and installed on the test machine, this command

# will be executed. Usually what is done is to ssh to the target box and

# run some test scripts. If you just want to boot test your patches

# comment PATCH_TEST out.

PATCH_TEST := ${SSH} "/usr/local/bin/ktest-test-script"

DEFAULTS IF DEFINED PATCH_TEST

PATCH_TEST_TYPE := test

DEFAULTS ELSE

PATCH_TEST_TYPE := boot

# If for some reason a file has a warning that one of your patches touch

# but you do not care about it, set IGNORE_WARNINGS to that commit(s)

# (space delimited)

#IGNORE_WARNINGS = 39eaf7ef884dcc44f7ff1bac803ca2a1dcf43544 6edb2a8a385f0cdef51dae37ff23e74d76d8a6ce

# If you are running a multi test, and the test failed on the first

# test but on, say the 5th patch. If you want to restart on the

# fifth patch, set PATCH_START1. This will make the first test start

# from this commit instead of the PATCH_START commit.

# Note, do not change this option. Just define PATCH_START1 in the

# top config (the one you pass to ktest.pl), and this will use it,

# otherwise it will just use PATCH_START if PATCH_START1 is not defined.

DEFAULTS IF NOT DEFINED PATCH_START1

PATCH_START1 := ${PATCH_START}

TEST_START IF ${TEST} == patchcheck

TEST_TYPE = patchcheck

MIN_CONFIG = ${PATCH_CONFIG}

TEST = ${PATCH_TEST}

PATCHCHECK_TYPE = ${PATCH_TEST_TYPE}

PATCHCHECK_START = ${PATCH_START1}

PATCHCHECK_END = ${PATCH_END}

CHECKOUT = ${PATCH_CHECKOUT}

TEST_START IF ${TEST} == patchcheck && ${MULTI}

TEST_TYPE = patchcheck

MIN_CONFIG = ${PATCH_CONFIG}

TEST = ${PATCH_TEST}

PATCHCHECK_TYPE = ${PATCH_TEST_TYPE}

PATCHCHECK_START = ${PATCH_START}

PATCHCHECK_END = ${PATCH_END}

CHECKOUT = ${PATCH_CHECKOUT}

# Use multi to test different compilers?

MAKE_CMD = CC=gcc-4.5.1 make

#

# This is an example of various tests that you can run

#

# The variable TEST can be of boot, build, randconfig, or test.

#

# Note that TEST is a variable created with ':=' and only exists

# throughout the config processing (not during the tests itself).

#

# The TEST option (defined with '=') is used to tell ktest.pl

# what test to run after a successful boot. The TEST option is

# persistent into the test runs.

#

# The config that includes this file may define a BOOT_TYPE

# variable that tells this config what type of boot test to run.

# If it's not defined, the below DEFAULTS will set the default

# to 'oldconfig'.

#

DEFAULTS IF NOT DEFINED BOOT_TYPE

BOOT_TYPE := oldconfig

# The config that includes this file may define a RUN_TEST

# variable that will tell this config what test to run.

# (what to set the TEST option to).

#

DEFAULTS IF NOT DEFINED RUN_TEST

# Requires that hackbench is in the PATH

RUN_TEST := ${SSH} hackbench 50

# If TEST is set to 'boot' then just build a kernel and boot

# the target.

TEST_START IF ${TEST} == boot

TEST_TYPE = boot

# Notice how we set the BUILD_TYPE option to the BOOT_TYPE variable.

BUILD_TYPE = ${BOOT_TYPE}

# Do not do a make mrproper.

BUILD_NOCLEAN = 1

# If you only want to build the kernel, and perhaps install

# and test it yourself, then just set TEST to build.

TEST_START IF ${TEST} == build

TEST_TYPE = build

BUILD_TYPE = ${BOOT_TYPE}

BUILD_NOCLEAN = 1

# Build, install, boot and test with a randconfg 10 times.

# It is important that you have set MIN_CONFIG in the config

# that includes this file otherwise it is likely that the

# randconfig will not have the neccessary configs needed to

# boot your box. This version of the test requires a min

# config that has enough to make sure the target has network

# working.

TEST_START ITERATE 10 IF ${TEST} == randconfig

MIN_CONFIG = ${CONFIG_DIR}/config-min-net

TEST_TYPE = test

BUILD_TYPE = randconfig

TEST = ${RUN_TEST}

# This is the same as above, but only tests to a boot prompt.

# The MIN_CONFIG used here does not need to have networking

# working.

TEST_START ITERATE 10 IF ${TEST} == randconfig && ${MULTI}

TEST_TYPE = boot

BUILD_TYPE = randconfig

MIN_CONFIG = ${CONFIG_DIR}/config-min

MAKE_CMD = make

# This builds, installs, boots and tests the target.

TEST_START IF ${TEST} == test

TEST_TYPE = test

BUILD_TYPE = ${BOOT_TYPE}

TEST = ${RUN_TEST}

BUILD_NOCLEAN = 1