<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/tools/testing/ktest/sample.conf, branch v3.1</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v3.1</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v3.1'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2011-07-16T01:57:25Z</updated>
<entry>
<title>ktest: Add prompt to use OUTPUT_MIN_CONFIG</title>
<updated>2011-07-16T01:57:25Z</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2011-07-16T01:57:25Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=35ce5952e62bc72520e6a7dbcfa4baf8c9f9eedb'/>
<id>urn:sha1:35ce5952e62bc72520e6a7dbcfa4baf8c9f9eedb</id>
<content type='text'>
If the defined OUTPUT_MIN_CONFIG in the make_min_config test exists,
then give a prompt to ask the user if they want to use that config
instead, as it is very often the case, especially when the test has been
interrupted. The OUTPUT_MIN_CONFIG is usually the config that one wants
to use to continue the test where they left off.

But if START_MIN_CONFIG is defined (thus the MIN_CONFIG is not the
default), then do not prompt, as it will be annoying if the user has
this as one of many tests, and the test pauses waiting for input, while
the user is sleeping.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>ktest: Use Kconfig dependencies to shorten time to make min_config</title>
<updated>2011-07-16T01:29:09Z</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2011-07-16T01:25:24Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b9066f6c0e215386d4b888eaedd739397b987421'/>
<id>urn:sha1:b9066f6c0e215386d4b888eaedd739397b987421</id>
<content type='text'>
To save time, the test does not just grab any option and test
it. The Kconfig files are examined to determine the dependencies
of the configs. If a config is chosen that depends on another
config, that config will be checked first. By checking the
parents first, we can eliminate whole groups of configs that
may have been enabled.

For example, if a USB device config is chosen and depends on
CONFIG_USB, the CONFIG_USB will be tested before the device.
If CONFIG_USB is found not to be needed, it, as well as all
configs that depend on it, will be disabled and removed from
the current min_config.

Note, the code from streamline_config (make localmodconfig)
was copied and used to find the dependencies in the Kconfig file.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>ktest: Add test type make_min_config</title>
<updated>2011-07-16T01:19:44Z</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2011-07-16T01:16:17Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=4c4ab1204fe4e201ece94c3062aa6b5eed670457'/>
<id>urn:sha1:4c4ab1204fe4e201ece94c3062aa6b5eed670457</id>
<content type='text'>
After doing a make localyesconfig, your kernel configuration may
not be the most useful minimum configuration. Having a true minimum
config that you can use against other configs is very useful if
someone else has a config that breaks on your code. By only forcing
those configurations that are truly required to boot your machine
will give you less of a chance that one of your set configurations
will make the bug go away. This will give you a better chance to
be able to reproduce the reported bug matching the broken config.

Note, this does take some time, and may require you to run the
test over night, or perhaps over the weekend. But it also allows
you to interrupt it, and gives you the current minimum config
that was found till that time.

Note, this test automatically assumes a BUILD_TYPE of oldconfig
and its test type acts like boot.

TODO: add a test version that makes the config do more than just
      boot, like having network access.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>ktest: Add IGNORE_WARNINGS to ignore warnings in some patches</title>
<updated>2011-06-15T00:46:25Z</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2011-06-15T00:46:25Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1990207d538885e678f374e3e79f454c2e6c7383'/>
<id>urn:sha1:1990207d538885e678f374e3e79f454c2e6c7383</id>
<content type='text'>
Doing a patchcheck test, there may be warnings that gcc produces which
may be OK, and the test should not fail on that commit. By adding a
IGNORE_WARNINGS option to list a space delimited SHA1s that are ignored
lets the user avoid having the test fail on certain commits.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>ktest: Have the testing tmp dir include machine name</title>
<updated>2011-06-15T00:43:59Z</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2011-06-15T00:42:19Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=4892063043282229c1296d86a2f86989ef30a97c'/>
<id>urn:sha1:4892063043282229c1296d86a2f86989ef30a97c</id>
<content type='text'>
As multiple tests may be executed by the same server, have the test
machine name add uniqueness to the value of the temp directory.
Otherwise the temp directories may overwrite each other's tests.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>ktest: Add POST/PRE_BUILD options</title>
<updated>2011-06-15T00:39:31Z</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2011-06-15T00:39:31Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=0bd6c1a38f57127eeb9444ed74cf5b65f36f563c'/>
<id>urn:sha1:0bd6c1a38f57127eeb9444ed74cf5b65f36f563c</id>
<content type='text'>
There are some cases that a patch may be needed to apply to the kernel
in patchcheck or bisect tests. Adding a PRE_BUILD option to apply the
patch and POST_BUILD to remove it, allows for this to be done easily.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>ktest: Add TEST_NAME option</title>
<updated>2011-06-13T14:38:48Z</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2011-06-13T14:38:48Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=9064af5206c26ce0d47621fef216b0c43d65d693'/>
<id>urn:sha1:9064af5206c26ce0d47621fef216b0c43d65d693</id>
<content type='text'>
Searching through several tests, it gets confusing which test result
is for which test. By adding the TEST_NAME option, the user can tell
which test result belongs to which test.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>ktest: Add CONFIG_BISECT_GOOD option</title>
<updated>2011-06-13T14:35:35Z</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2011-06-13T14:35:35Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=30f75da5ff475f1f455c0b009f3c06767963c54f'/>
<id>urn:sha1:30f75da5ff475f1f455c0b009f3c06767963c54f</id>
<content type='text'>
Currently the config_bisect compares the min config with the
CONFIG_BISECT config. There may be another config that we know
is good that we want to ignore configs on. By passing in this
config it will ignore the options that are set in the good config.

Note: This only ignores the config, it does not (yet) handle
options that are different between the two configs. If the good
config has "SLAB" set and the bad config has "SLUB" it will not
find the bug if the bug had to do with changing these two options.

This is something that I intend to implement in the future.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>ktest: Add detection of triple faults</title>
<updated>2011-06-13T14:30:00Z</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2011-06-13T14:30:00Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=f1a5b96219e3483ab519bed9bb04cc8fadf74816'/>
<id>urn:sha1:f1a5b96219e3483ab519bed9bb04cc8fadf74816</id>
<content type='text'>
When a triple fault happens in a test, no call trace nor panic
is displayed. Instead, the system reboots to the good kernel.
Since the good kernel may display a boot prompt that matches the
success string, ktest may think that the test succeeded, when it
did not.

Detecting triple faults is tricky because it is hard to generalize
what a reboot looks like. The best that we can come up with for now
is to examine the Linux banner. If we detect that the Linux banner
matches the test we want to test, then look to see if we hit another
Linux banner with a different kernel is booted. This can be assumed
to be a triple fault.

We can't just check for two Linux banners because things like
early printk may cause the Linux banner to be displayed twice. Checking
for different kernel versions should be the safe bet.

If this for some reason detects a false triple boot. A new ktest
config option is also created:

 DETECT_TRIPLE_FAULT

This can be set to 0 to disable this checking.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
</entry>
<entry>
<title>ktest: Allow options to be used by other options</title>
<updated>2011-05-20T19:48:59Z</updated>
<author>
<name>Steven Rostedt</name>
<email>srostedt@redhat.com</email>
</author>
<published>2011-05-20T19:48:59Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=2a62512bceb44ad45f78aa7ca0e9cfaee9eae46f'/>
<id>urn:sha1:2a62512bceb44ad45f78aa7ca0e9cfaee9eae46f</id>
<content type='text'>
There are cases where one ktest option may be used within another
ktest option. Allow them to be reused just like config variables
but there are evaluated at time of test not config processing time.

Thus having something like:

MAKE_CMD = make ARCH=${ARCH}

TEST_START
ARCH = powerpc

TEST_START
ARCH = arm

Will have the arch defined for each test iteration.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
</entry>
</feed>
