Searched full:test (Results 1 – 25 of 394) sorted by relevance
12345678910>>...16
/Documentation/dev-tools/kunit/ |
D | usage.rst | 21 to unit test code that was otherwise un-unit-testable. 39 A `unit test <https://martinfowler.com/bliki/UnitTest.html>`_ is a test that 50 Test Cases 53 The fundamental unit in KUnit is the test case. A test case is a function with 54 the signature ``void (*)(struct kunit *test)``. It calls a function to be tested 59 void example_test_success(struct kunit *test) 63 void example_test_failure(struct kunit *test) 65 KUNIT_FAIL(test, "This test never passes."); 71 a special expectation that logs a message and causes the test case to fail. 76 something in a test. An expectation is called like a function. A test is made [all …]
|
D | style.rst | 4 Test Style and Nomenclature 24 and subsystems. A test suite is a group of tests which test a related area of 25 the kernel, and a subsystem is a set of test suites which test different parts 31 Every test suite must belong to a subsystem. A subsystem is a collection of one 32 or more KUnit test suites which test the same driver or part of the kernel. A 33 rule of thumb is that a test subsystem should match a single kernel module. If 39 Test subsystems should be named after the code being tested, either after the 40 module (wherever possible), or after the directory or files being tested. Test 43 If a test subsystem name has multiple components, they should be separated by 44 underscores. *Do not* include "test" or "kunit" directly in the subsystem name [all …]
|
D | faq.rst | 12 A `unit test <https://martinfowler.com/bliki/UnitTest.html>`_ is supposed to 13 test a single unit of code in isolation, hence the name. A unit test should be 15 paths to be tested in the code under test; this is only possible if the code 16 under test is very small and does not have any external dependencies outside of 17 the test's control like hardware. 20 require installing the kernel on a test machine or in a VM and all require 21 tests to be written in userspace and run on the kernel under test; this is true 42 What is the difference between a unit test and these other kinds of tests? 45 test, or an end-to-end test. 47 - A unit test is supposed to test a single unit of code in isolation, hence the [all …]
|
D | start.rst | 15 Linux, and formats the test results. 31 test targets as well. The ``.kunitconfig`` should also contain any other config 114 Build and run your kernel as usual. Test output will be written to the kernel 122 Writing your first test 125 In your kernel repo let's add some code that we can test. Create a file 158 Now we are ready to write the test. The test will be in 159 ``drivers/misc/example-test.c``: 163 #include <kunit/test.h> 166 /* Define the test cases. */ 168 static void misc_example_add_test_basic(struct kunit *test) [all …]
|
D | index.rst | 23 Googletest/Googlemock for C++. KUnit provides facilities for defining unit test 24 cases, grouping related test cases into test suites, providing common 34 <http://user-mode-linux.sourceforge.net>`_ kernel, runs it, and parses the test 43 A unit test is supposed to test a single unit of code in isolation, hence the 44 name. A unit test should be the finest granularity of testing and as such should 45 allow all possible code paths to be tested in the code under test; this is only 46 possible if the code under test is very small and does not have any external 47 dependencies outside of the test's control like hardware. 53 KUnit and KUnit tests can be built as modules and tests will run when the test 80 tests; this means that tests are likely to break, unlikely to test a lot of [all …]
|
/Documentation/devicetree/ |
D | of_unittest.rst | 12 This document explains how the test data required for executing OF unittest 21 OF Selftest has been designed to test the interface (include/linux/of.h) 27 2. Test-data 31 the test data required for executing the unit tests automated in 59 2.1. Adding the test data 108 Before executing OF unittest, it is required to attach the test data to 113 __dtb_testcases_begin - address marking the start of test data blob 114 __dtb_testcases_end - address marking the end of test data blob 118 then it attaches the unflattened test data tree to the live tree, else it 122 live tree as explained below. To explain the same, the test data tree described [all …]
|
/Documentation/driver-api/dmaengine/ |
D | dmatest.rst | 2 DMA Test Guide 7 This small document introduces how to test DMA drivers using dmatest module. 10 The test suite works only on the channels that have at least one 18 Part 1 - How to build the test module 23 Device Drivers -> DMA Engine support -> DMA Test client 47 Example of multi-channel test usage (new in the 5.0 kernel):: 76 Note that running a new test will not stop any in progress test. 78 The following command returns the state of the test. :: 82 To wait for test completion userpace can poll 'run' until it is false, or use 84 initialization to pause until a test run has completed, while reading [all …]
|
/Documentation/power/ |
D | basic-pm-debugging.rst | 18 test at least a couple of times in a row for confidence. [This is necessary, 44 a) Test modes of hibernation 50 core run in a test mode. There are 5 test modes available: 53 - test the freezing of processes 56 - test the freezing of processes and suspending of devices 59 - test the freezing of processes, suspending of devices and platform 63 - test the freezing of processes, suspending of devices, platform 67 - test the freezing of processes, suspending of devices, platform global 77 /sys/power/pm_test (eg. "devices" to test the freezing of processes and 79 to use the "devices" test mode along with the "platform" mode of hibernation, [all …]
|
D | drivers-testing.rst | 7 1. Preparing the test system 10 Unfortunately, to effectively test the support for the system-wide suspend and 18 Of course, for this purpose the test system has to be known to suspend and 20 resolve all suspend/resume-related problems in the test system before you start 27 Once you have resolved the suspend/resume-related problems with your test system 28 without the new driver, you are ready to test it: 30 a) Build the driver as a module, load it and try the test modes of hibernation 36 c) Compile the driver directly into the kernel and try the test modes of 42 e) Try the test modes of suspend (see:
|
/Documentation/admin-guide/aoe/ |
D | udev-install.sh | 10 if test -z "$conf"; then 11 if test -r /etc/udev/udev.conf; then 15 if test -z "$conf" || test ! -r "$conf"; then 26 if test -z "$rules_d" ; then 29 if test ! -d "$rules_d"; then
|
D | status.sh | 15 #test -z "`mount | grep sysfs`" && { 16 test ! -d "$sysd/block" && { 23 test $d = end && continue
|
/Documentation/dev-tools/ |
D | kselftest.rst | 18 in safe mode with a limited scope. In limited mode, cpu-hotplug test is 20 hotplug test is run on 2% of hotplug capable memory instead of 10%. 23 userspace may wish to use the `Test Harness`_. Tests that need to be 24 run in kernel space may wish to use a `Test Module`_. 61 Kselftest supports "summary" option to make it easier to understand the test 62 results. Please find the detailed individual test results for each test in 74 single test to run, or a list of tests to run. 156 The `-c` option can be used to run all the tests from a test collection, or 212 TEST_PROGS are for test shell scripts. Please ensure shell script has 220 test. [all …]
|
D | gcov.rst | 21 * test improvement (how do I change my test to cover these lines?) 119 Separated build and test machines 127 a) gcov is run on the TEST machine 129 The gcov tool version on the test machine must be compatible with the 131 copied from build to test machine: 142 exact same file system location on the test machine as on the build 148 The following files need to be copied after each test case from test 162 /tmp/coverage: location of the files copied from the test machine 236 echo "$DEST successfully created, copy to test system and unpack with:" 246 Sample script to gather coverage data files on the test machine
|
/Documentation/i2c/ |
D | slave-testunit-backend.rst | 9 This backend can be used to trigger test cases for I2C bus masters which 28 0x00 CMD - which test to trigger 29 0x01 DATAL - configuration byte 1 for the test 30 0x02 DATAH - configuration byte 2 for the test 31 0x03 DELAY - delay in n * 10ms until test is started 37 DELAY is a generic parameter which will delay the execution of the test in CMD. 53 This is useful to test if your bus master driver is handling multi-master 55 the bus. If the bus master under test also wants to access the bus at the same 65 This test will send an SMBUS_HOST_NOTIFY message to the host. Note that the
|
/Documentation/networking/device_drivers/ethernet/cirrus/ |
D | cs89x0.rst | 46 5.2.1 Diagnostic Self-Test 47 5.2.2 Diagnostic Network Test 383 the CS8900/20 Setup Utility can be used to test the functionality of the 384 adapter and its network connection. Use the diagnostics 'Self Test' option to 385 test the functionality of the adapter with the hardware configuration you have 386 assigned. You can use the diagnostics 'Network Test' to test the ability of the 406 * Select 'Self-Test' to test the adapter's basic functionality. 407 * Select 'Network Test' to test the network connection and cabling. 410 5.2.1. Diagnostic Self-test 413 The diagnostic self-test checks the adapter's basic functionality as well as [all …]
|
/Documentation/admin-guide/cgroup-v1/ |
D | memcg_test.rst | 157 When you do test to do racy case, it's good test to set memcg's limit 158 to be very small rather than GB. Many races found in the test under 169 SwapCache. Test with shmem/tmpfs is always good test. 174 For NUMA, migration is an another special case. To do easy test, cpuset 212 memory hotplug test is one of good test. 220 This is an easy way to test page migration, too. 225 When using hierarchy, mkdir/rmdir test should be done. 247 Mounting with other subsystems is a good test because there is a 263 For example, test like following is good: 268 # mkdir /cgroup/test [all …]
|
/Documentation/litmus-tests/ |
D | README | 7 For more information about how to "run" a litmus test or how to generate 8 a kernel test module based on a litmus test, please see 16 Test that an atomic RMW followed by a smp_mb__after_atomic() is 21 Test that atomic_set() cannot break the atomicity of atomic RMWs.
|
/Documentation/PCI/endpoint/ |
D | index.rst | 12 pci-test-function 13 pci-test-howto 15 function/binding/pci-test
|
D | pci-test-howto.rst | 4 PCI Test User Guide 9 This document is a guide to help users use pci-epf-test function driver 44 Creating pci-epf-test Device 48 pci-epf-test device, the following commands can be used:: 54 The "mkdir func1" above creates the pci-epf-test function device that will 66 when the device is bound to the driver. The pci-epf-test driver populates 75 Configuring pci-epf-test Device 78 The user can configure the pci-epf-test device using configfs entry. In order 88 Binding pci-epf-test Device to EP Controller 123 Using Endpoint Test function Device
|
/Documentation/admin-guide/device-mapper/ |
D | log-writes.rst | 87 <run test> 104 Say you want to test fsync on your file system. You would do something like 112 mount /dev/mapper/log /mnt/btrfs-test 113 <some test that does fsync at the end> 115 md5sum /mnt/btrfs-test/foo 116 umount /mnt/btrfs-test 120 mount /dev/sdb /mnt/btrfs-test 121 md5sum /mnt/btrfs-test/foo 132 mount /dev/mapper/log /mnt/btrfs-test 134 btrfs filesystem balance /mnt/btrfs-test [all …]
|
/Documentation/gpu/ |
D | vkms.rst | 21 - Add igt test to check cleared alpha value for XRGB plane format. 23 - Add igt test to check extreme alpha values i.e. fully opaque and fully 30 module. Use/Test-cases: 32 - Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of 61 For all of these, we also want to review the igt test coverage and make sure all 81 allows us to test them together, to test synchronization and lots of other 82 features. Also, this allows compositors to test whether they work correctly on
|
/Documentation/admin-guide/media/ |
D | misc-cardlist.rst | 14 Test drivers 17 In order to test userspace applications, there's a number of virtual 18 drivers, with provide test functionality, simulating real hardware 27 vivid Virtual Video Test Driver
|
/Documentation/locking/ |
D | locktorture.rst | 2 Kernel Lock Torture Test Operation 13 grepping for "torture"). The test is started when the module is loaded, 17 This torture test consists of creating a number of kernel threads which 80 The number of seconds to run the test before terminating 81 the test and powering off the system. The default is 82 zero, which disables test termination and system shutdown. 109 The length of time to run the test before pausing for this 112 Specifying "stutter=0" causes the test to run continuously 116 The number of seconds to keep the test threads affinitied
|
/Documentation/leds/ |
D | leds-blinkm.rst | 61 blue green red test 64 and a test sequence. 72 #Write into test to start test sequence!# 74 $ echo 1 > test
|
/Documentation/misc-devices/ |
D | pci-endpoint-test.rst | 4 Driver for PCI Endpoint Test Function 13 The PCI driver for the test device performs the following tests: 23 This misc driver creates /dev/pci-endpoint-test.<num> for every 56 .. [1] Documentation/PCI/endpoint/function/binding/pci-test.rst
|
12345678910>>...16