| /linux/tools/testing/selftests/bpf/prog_tests/ |
| H A D | arg_parsing.c | 9 set->tests = NULL; in init_test_filter_set()
17 for (j = 0; j < set->tests[i].subtest_cnt; j++) in free_test_filter_set()
18 free((void *)set->tests[i].subtests[j]); in free_test_filter_set()
19 free(set->tests[i].subtests); in free_test_filter_set()
20 free(set->tests[i].name); in free_test_filter_set()
23 free(set->tests); in free_test_filter_set()
36 if (!ASSERT_OK_PTR(set.tests, "test filters initialized")) in test_parse_test_list()
38 ASSERT_EQ(set.tests[0].subtest_cnt, 0, "subtest filters count"); in test_parse_test_list()
39 ASSERT_OK(strcmp("arg_parsing", set.tests[0].name), "subtest name"); in test_parse_test_list()
46 if (!ASSERT_OK_PTR(set.tests, "test filters initialized")) in test_parse_test_list()
[all …]
|
| H A D | obj_name.c | 10 } tests[] = { in test_obj_name() local
23 for (i = 0; i < ARRAY_SIZE(tests); i++) { in test_obj_name()
24 size_t name_len = strlen(tests[i].name) + 1; in test_obj_name()
37 memcpy(attr.prog_name, tests[i].name, ncopy); in test_obj_name()
40 CHECK((tests[i].success && fd < 0) || in test_obj_name()
41 (!tests[i].success && fd >= 0) || in test_obj_name()
42 (!tests[i].success && errno != tests[i].expected_errno), in test_obj_name()
45 fd, tests[i].success, errno, tests[i].expected_errno); in test_obj_name()
59 memcpy(attr.map_name, tests[i].name, ncopy); in test_obj_name()
61 CHECK((tests[i].success && fd < 0) || in test_obj_name()
[all …]
|
| H A D | global_data.c | 18 } tests[] = { in test_global_data_number() local
32 for (i = 0; i < ARRAY_SIZE(tests); i++) { in test_global_data_number()
33 err = bpf_map_lookup_elem(map_fd, &tests[i].key, &num); in test_global_data_number()
34 CHECK(err || num != tests[i].num, tests[i].name, in test_global_data_number()
36 err, num, tests[i].num); in test_global_data_number()
53 } tests[] = { in test_global_data_string() local
61 for (i = 0; i < ARRAY_SIZE(tests); i++) { in test_global_data_string()
62 err = bpf_map_lookup_elem(map_fd, &tests[i].key, str); in test_global_data_string()
63 CHECK(err || memcmp(str, tests[i].str, sizeof(str)), in test_global_data_string()
64 tests[i].name, "err %d result \'%s\' expected \'%s\'\n", in test_global_data_string()
[all …]
|
| /linux/Documentation/dev-tools/kunit/ |
| H A D | style.rst | 7 To make finding, writing, and using KUnit tests as simple as possible, it is
9 below. While it is possible to write KUnit tests which do not follow these rules,
10 they may break some tooling, may conflict with other tests, and may not be run
15 1. Porting tests to KUnit which are already known with an existing name.
16 2. Writing tests which would cause serious problems if automatically run. For
20 Subsystems, Suites, and Tests
23 To make tests easy to find, they are grouped into suites and subsystems. A test
24 suite is a group of tests which test a related area of the kernel. A subsystem
36 unsure, follow the conventions set by tests in similar areas.
44 unless we are actually testing other tests or the kunit framework itself. For
[all …]
|
| H A D | run_wrapper.rst | 4 Running tests with kunit_tool
7 We can either run KUnit tests using kunit_tool or can run tests
8 manually, and then use kunit_tool to parse the results. To run tests
13 tests, and formats the test results.
35 - ``--timeout`` sets a maximum amount of time for tests to run.
45 tests we want to run independently, or if we want to use pre-defined
64 If we want to run a specific set of tests (rather than those listed
70 specific set of tests. This file contains the regular Kernel configs
72 contains any other config options required by the tests (For example:
73 dependencies for features under tests, configs that enable/disable
[all …]
|
| H A D | run_manual.rst | 4 Run Tests without kunit_tool
8 with other systems, or run tests on real hardware), we can
12 possible that tests may reduce the stability or security of
18 KUnit tests can run without kunit_tool. This can be useful, if:
26 tests can also be built by enabling their config options in our
27 ``.config``. KUnit tests usually (but don't always) have config options
28 ending in ``_KUNIT_TEST``. Most tests can either be built as a module,
34 automatically enable all tests with satisfied dependencies. This is
41 enabled by default. To ensure that tests are executed as expected,
45 the tests. If the tests are built-in, they will run automatically on the
[all …]
|
| H A D | running_tips.rst | 4 Tips For Running KUnit Tests
25 Running a subset of tests
28 ``kunit.py run`` accepts an optional glob argument to filter tests. The format
31 Say that we wanted to run the sysctl tests, we could do so via:
38 We can filter down to just the "write" tests via:
45 We're paying the cost of building more tests than we need this way, but it's
49 However, if we wanted to define a set of tests in a less ad hoc way, the next
52 Defining a set of tests
56 ``--kunitconfig`` flag. So if you have a set of tests that you want to run on a
60 E.g. kunit has one for its tests:
[all …]
|
| H A D | start.rst | 8 teaching how to run existing tests and then how to write a simple test case,
16 Running tests with kunit_tool
19 tests, and formats the test results. From the kernel repository, you
50 The tests will pass or fail.
59 Selecting which tests to run
62 By default, kunit_tool runs all tests reachable with minimal configuration,
64 you can select which tests to run by:
67 - `Filtering tests by name`_ to select specifically which compiled tests to run.
84 Before running the tests, kunit_tool ensures that all config options
91 options required to run the desired tests, including their dependencies.
[all …]
|
| H A D | index.rst | 27 unit tests within the Linux kernel. Using KUnit, you can define groups
28 of test cases called test suites. The tests either run on kernel boot
35 KUnit tests are part of the kernel, written in the C (programming)
38 completion, KUnit can run around 100 tests in less than 10 seconds.
47 that configures the Linux kernel, runs KUnit tests under QEMU or UML
55 - Provides a framework for writing unit tests.
56 - Runs tests on any kernel architecture.
68 A unit test tests a single unit of code in isolation. A unit test is the finest
74 Write Unit Tests
77 To write good unit tests, there is a simple but powerful pattern:
[all …]
|
| /linux/lib/kunit/ |
| H A D | Kconfig | 6 tristate "KUnit - Enable support for unit tests"
9 Enables support for kernel unit tests (KUnit), a lightweight unit
10 testing and mocking framework for the Linux kernel. These tests are
28 bool "Enable KUnit tests which print BUG stacktraces"
33 Enables fault handling tests for the KUnit framework. These tests may
42 Enables the unit tests for the KUnit test framework. These tests test
43 the KUnit test framework itself; the tests are both written using
60 tristate "All KUnit tests with satisfied dependencies"
62 Enables all KUnit tests, if they can be enabled.
63 KUnit tests run during boot and output the results to the debug log
[all …]
|
| /linux/tools/testing/selftests/ |
| H A D | run_kselftest.sh | 4 # Run installed kselftest tests.
10 TESTS="$BASE_DIR"/kselftest-list.txt
11 if [ ! -r "$TESTS" ] ; then
12 echo "$0: Could not find list of tests to run ($TESTS)" >&2
15 available="$(cat "$TESTS")"
28 -c | --collection COLLECTION Run all tests from COLLECTION
30 -d | --dry-run Don't actually run any tests
31 -f | --no-error-on-fail Don't exit with an error just because tests failed
40 TESTS
[all...] |
| /linux/tools/testing/selftests/sync/ |
| H A D | Makefile | 10 # lib.mk TEST_CUSTOM_PROGS var is for custom tests that need special
18 TESTS += sync_alloc.o
19 TESTS += sync_fence.o
20 TESTS += sync_merge.o
21 TESTS += sync_wait.o
22 TESTS += sync_stress_parallelism.o
23 TESTS += sync_stress_consumer.o
24 TESTS += sync_stress_merge.o
27 TESTS := $(patsubst %,$(OUTPUT)/%,$(TESTS)) macro
29 $(TEST_CUSTOM_PROGS): $(TESTS) $(OBJS)
[all …]
|
| /linux/Documentation/rust/ |
| H A D | testing.rst | 9 There are three sorts of tests:
11 - The KUnit tests.
12 - The ``#[test]`` tests.
15 The KUnit tests
18 These are the tests that come from the examples in the Rust documentation. They
19 get transformed into KUnit tests.
24 These tests can be run via KUnit. For example via ``kunit_tool`` (``kunit.py``)
37 Kernel hacking -> Kernel Testing and Coverage -> KUnit - Enable support for unit tests
43 KUnit tests are documentation tests
46 These documentation tests are typically examples of usage of any item (e.g.
[all …]
|
| /linux/drivers/firewire/ |
| H A D | Kconfig | 22 tristate "KUnit tests for layout of structure in UAPI" if !KUNIT_ALL_TESTS
26 This builds the KUnit tests whether structures exposed to user
29 KUnit tests run during boot and output the results to the debug
34 For more information on KUnit and unit tests in general, refer
38 tristate "KUnit tests for device attributes" if !KUNIT_ALL_TESTS
42 This builds the KUnit tests for device attribute for node and
45 KUnit tests run during boot and output the results to the debug
50 For more information on KUnit and unit tests in general, refer
54 tristate "KUnit tests for packet serialization/deserialization" if !KUNIT_ALL_TESTS
58 This builds the KUnit tests for packet serialization and
[all …]
|
| /linux/tools/memory-model/ |
| H A D | README | 12 the state space of small litmus tests.
67 explore the state space of small litmus tests. Documentation describing
69 tests is available in tools/memory-model/Documentation/litmus-tests.txt.
71 Example litmus tests may be found in the Linux-kernel source tree:
73 tools/memory-model/litmus-tests/
74 Documentation/litmus-tests/
76 Several thousand more example litmus tests are available here:
82 Documentation describing litmus tests and how to use them may be found
85 tools/memory-model/Documentation/litmus-tests
[all...] |
| /linux/Documentation/dev-tools/ |
| H A D | testing-overview.rst | 13 Writing and Running Tests
16 The bulk of kernel tests are written using either the kselftest or KUnit
17 frameworks. These both provide infrastructure to help make running tests and
18 groups of tests easier, as well as providing helpers to aid in writing new
19 tests.
32 KUnit tests therefore are best written against small, self-contained parts
40 This also makes KUnit tests very fast to build and run, allowing them to be
48 largely implemented in userspace, and tests are normal userspace scripts or
51 This makes it easier to write more complicated tests, or tests which need to
56 work around this, some tests include a companion kernel module which exposes
[all …]
|
| /linux/Documentation/misc-devices/ |
| H A D | pci-endpoint-test.rst | 11 The "pci_endpoint_test" driver can be used to perform the following tests.
13 The PCI driver for the test device performs the following tests:
25 should be used to perform the above tests.
31 Tests the BAR. The number of the BAR to be tested
34 Tests legacy IRQ
36 Tests message signalled interrupts. The MSI number
39 Tests message signalled interrupts. The MSI-X number
47 Perform write tests. The size of the buffer should be passed
50 Perform read tests. The size of the buffer should be passed
53 Perform read tests. The size of the buffer should be passed
|
| /linux/tools/testing/selftests/arm64/signal/ |
| H A D | README | 4 Signals Tests
7 - Tests are built around a common main compilation unit: such shared main
15 executable is used for each test since many tests complete successfully
20 - New tests can be simply defined in testcases/ dir providing a proper struct
27 - 'mangle_' tests: a real signal (SIGUSR1) is raised and used as a trigger
31 - 'fake_sigreturn_' tests: a brand new custom artificial sigframe structure
33 real signal return. This kind of tests does not use a trigger usually and
36 - Most of these tests are successfully passing if the process gets killed by
38 kind of tests it is extremely easy in fact to end-up injecting other
40 be really sure that the tests are really addressing what they are meant
[all …]
|
| /linux/tools/testing/selftests/mm/ |
| H A D | run_vmtests.sh | 7 # If you do not YOUR TESTS WILL NOT RUN IN THE CI.
22 -a: run all tests, including extra ones (other than destructive ones)
23 -t: specify specific categories to tests to run
26 -d: run destructive tests
28 The default behavior is to run required tests only. If -a is specified,
29 will run all tests.
31 Alternatively, specific groups tests can be run by passing a string
35 tests for mmap(2)
37 tests for gup
39 tests fo
[all...] |
| /linux/tools/testing/selftests/drivers/net/ |
| H A D | README.rst | 3 Running driver tests
6 Networking driver tests are executed within kselftest framework like any
7 other tests. They support testing both real device drivers and emulated /
13 By default, when no extra parameters are set or exported, tests execute
16 In this mode the tests are indistinguishable from other selftests and
22 Executing tests against a real device requires external preparation.
23 The netdevice against which tests will be run must exist, be running
27 the tests against a real device.
29 The current support for bash tests restricts the use of the same interface name
36 All tests i
[all...] |
| /linux/drivers/of/unittest-data/ |
| H A D | testcases_common.dtsi | 15 #include "tests-phandle.dtsi"
16 #include "tests-interrupts.dtsi"
17 #include "tests-match.dtsi"
18 #include "tests-address.dtsi"
19 #include "tests-platform.dtsi"
20 #include "tests-overlay.dtsi"
21 #include "tests-lifecycle.dtsi"
|
| /linux/tools/testing/selftests/livepatch/ |
| H A D | README | 2 Livepatch Self Tests
5 This is a small set of sanity tests for the kernel livepatching.
9 buffer and parsed for expected messages. (Note: the tests will compare
19 Building the tests
22 To only build the tests without running them, run:
29 Running the tests
35 tested on systems with different kABI, ensuring they the tests are backwards
47 Adding tests
53 "livepatch:" and "test_klp" strings, so tests be sure to include one of
|
| /linux/tools/memory-model/scripts/ |
| H A D | README | 10 Run all litmus tests in the litmus-tests directory, checking
16 Run all litmus tests in the https://github.com/paulmckrcu/litmus
23 Run all litmus tests having .litmus.out files from previous
34 Check the specified list of litmus tests against their "Result:"
41 Compare output from two different runs of the same litmus tests,
42 with the absolute pathnames of the tests to run provided one
48 Run all litmus tests having no more than the specified number
61 For all new or updated litmus tests having no more than the
72 Run the litmus tests whose absolute pathnames are provided one
110 to LKMM introduces a new primitive for which litmus tests already existed.
|
| /linux/tools/testing/memblock/ |
| H A D | README | 19 instance throughout the duration of the test. To ensure that tests don't affect
24 introduced memblock simulator (commit 16802e55dea9 ("memblock tests: Add
32 To run the tests, build the main target and run it:
38 append the `-v` options when you run the tests:
58 allocation functions. Tests for each group are defined in dedicated files, as it
67 |-- tests
68 | |-- alloc_api.(c|h) -- memblock_alloc tests
69 | |-- alloc_helpers_api.(c|h) -- memblock_alloc_from tests
70 | |-- alloc_nid_api.(c|h) -- memblock_alloc_try_nid tests
71 | |-- basic_api.(c|h) -- memblock_add/memblock_reserve/... tests
[all …]
|
| /linux/tools/perf/tests/ |
| H A D | tests-scripts.c | 19 #include "tests-scripts.h"
26 #include "tests.h"
35 "./tools/perf/tests/shell", in shell_tests__dir_fd()
36 "./tests/shell", in shell_tests__dir_fd()
37 "./source/tests/shell" in shell_tests__dir_fd()
62 scnprintf(path, sizeof(path), "%s/tests/shell", path2); in shell_tests__dir_fd()
66 scnprintf(path, sizeof(path), "%s/source/tests/shell", path2); in shell_tests__dir_fd()
73 scnprintf(path, sizeof(path), "%s/tests/shell", exec_path); in shell_tests__dir_fd()
176 struct test_case *tests; in append_script() local
189 tests = calloc(2, sizeof(*tests)); in append_script()
[all …]
|