요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
============================
Run Tests without kunit_tool
============================
If we do not want to use kunit_tool (For example: we want to integrate
with other systems, or run tests on real hardware), we can
include KUnit in any kernel, read out results, and parse manually.
.. note:: KUnit is not designed for use in a production system. It is
possible that tests may reduce the stability or security of
the system.
Configure the Kernel
====================
KUnit tests can run without kunit_tool. This can be useful, if:
- We have an existing kernel configuration to test.
- Need to run on real hardware (or using an emulator/VM kunit_tool
does not support).
- Wish to integrate with some existing testing systems.
KUnit is configured with the ``CONFIG_KUNIT`` option, and individual
tests can also be built by enabling their config options in our
``.config``. KUnit tests usually (but don't always) have config options
ending in ``_KUNIT_TEST``. Most tests can either be built as a module,
or be built into the kernel.
.. note ::
We can enable the ``KUNIT_ALL_TESTS`` config option to
automatically enable all tests with satisfied dependencies. This is
a good way of quickly testing everything applicable to the current
config.
Once we have built our kernel (and/or modules), it is simple to run
the tests. If the tests are built-in, they will run automatically on the
kernel boot. The results will be written to the kernel log (``dmesg``)
in TAP format.
If the tests are built as modules, they will run when the module is
loaded.
.. code-block :: bash
# modprobe example-test
The results will appear in TAP format in ``dmesg``.
debugfs
=======
KUnit can be accessed from userspace via the debugfs filesystem (See more
information about debugfs at Documentation/filesystems/debugfs.rst).
If ``CONFIG_KUNIT_DEBUGFS`` is enabled, the KUnit debugfs filesystem is
mounted at /sys/kernel/debug/kunit. You can use this filesystem to perform
the following actions.
Retrieve Test Results
=====================
You can use debugfs to retrieve KUnit test results. The test results are
accessible from the debugfs filesystem in the following read-only file:
.. code-block :: bash
/sys/kernel/debug/kunit/<test_suite>/results
The test results are printed in a KTAP document. Note this document is separate
to the kernel log and thus, may have different test suite numbering.
Run Tests After Kernel Has Booted
=================================
You can use the debugfs filesystem to trigger built-in tests to run after
boot. To run the test suite, you can use the following command to write to
the ``/sys/kernel/debug/kunit/<test_suite>/run`` file:
.. code-block :: bash
echo "any string" > /sys/kernel/debugfs/kunit/<test_suite>/run
As a result, the test suite runs and the results are printed to the kernel
log.
However, this feature is not available with KUnit suites that use init data,
because init data may have been discarded after the kernel boots. KUnit
suites that use init data should be defined using the
kunit_test_init_section_suites() macro.
Also, you cannot use this feature to run tests concurrently. Instead a test
will wait to run until other tests have completed or failed.
.. note ::
For test authors, to use this feature, tests will need to correctly initialise
and/or clean up any data, so the test runs correctly a second time.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
kunit_tool 없이 실행하는 이유
1-14SPDX 라이선스 식별자: GPL-2.0
kunit_tool 없이 테스트 실행
다른 시스템과 통합하거나 실제 hardware에서 테스트하려는 경우처럼 kunit_tool을 사용하지 않으려면 임의의 kernel에 KUnit을 포함하고 결과를 읽어 직접 parsing할 수 있습니다.
참고: KUnit은 production system에서 사용하도록 설계되지 않았습니다. 테스트가 시스템의 안정성이나 보안을 낮출 수 있습니다.
Kernel 구성과 built-in·module 실행
15-51Kernel 구성
KUnit test는 kunit_tool 없이 실행할 수 있습니다. 기존 kernel configuration을 검사하거나, 실제 hardware 또는 kunit_tool이 지원하지 않는 emulator와 VM에서 실행하거나, 기존 testing system과 통합할 때 유용합니다.
KUnit은 `CONFIG_KUNIT` option으로 구성합니다. 개별 테스트도 `.config`에서 해당 config option을 활성화해 build할 수 있습니다. KUnit test option은 보통 `_KUNIT_TEST`로 끝나지만 항상 그런 것은 아닙니다. 대부분의 테스트는 module 또는 built-in으로 build할 수 있습니다.
참고: `KUNIT_ALL_TESTS` config option을 활성화하면 dependency가 충족된 모든 테스트를 자동으로 켤 수 있습니다. 현재 config에 적용 가능한 모든 테스트를 빠르게 실행하는 좋은 방법입니다.
Kernel과 module을 build한 뒤 테스트 실행은 간단합니다. Built-in 테스트는 kernel boot 때 자동 실행되며 결과를 TAP 형식으로 kernel log인 `dmesg`에 씁니다.
Module로 build한 테스트는 module을 load할 때 실행됩니다.
# modprobe example-test결과는 `dmesg`에 TAP 형식으로 나타납니다.
같은 test suite가 built-in 또는 module 구성에 따라 서로 다른 시점에 실행됩니다.
debugfs에서 결과 조회
52-74debugfs
KUnit은 userspace에서 debugfs filesystem을 통해 접근할 수 있습니다. Debugfs 자체는 `Documentation/filesystems/debugfs.rst`를 참조하십시오.
`CONFIG_KUNIT_DEBUGFS`를 활성화하면 KUnit debugfs filesystem이 `/sys/kernel/debug/kunit`에 mount되며 다음 작업을 수행할 수 있습니다.
Test Result 조회
Debugfs에서 KUnit test result를 조회할 수 있습니다. 결과는 다음 read-only file에 있습니다.
/sys/kernel/debug/kunit/<test_suite>/results결과는 KTAP document로 출력됩니다. 이 document는 kernel log와 별개이므로 test suite numbering이 다를 수 있습니다.
Kernel log와 debugfs 결과는 별도 KTAP 문서이므로 numbering이 다를 수 있습니다.
Boot 이후 built-in suite 재실행
75-100Kernel boot 이후 테스트 실행
Debugfs filesystem을 사용해 boot 뒤 built-in test 실행을 trigger할 수 있습니다. Test suite를 실행하려면 `/sys/kernel/debug/kunit/<test_suite>/run` file에 다음과 같이 씁니다.
echo "any string" > /sys/kernel/debugfs/kunit/<test_suite>/run원문 command의 `/sys/kernel/debugfs/kunit/...` 경로는 그대로 보존했습니다. 앞 문단이 설명한 mount 경로는 `/sys/kernel/debug/kunit`입니다.
그 결과 test suite가 실행되고 결과가 kernel log에 출력됩니다.
Init data를 사용하는 KUnit suite에서는 이 기능을 사용할 수 없습니다. Kernel boot 뒤 init data가 이미 버려졌을 수 있기 때문입니다. Init data를 사용하는 suite는 `kunit_test_init_section_suites()` macro로 정의해야 합니다.
이 기능으로 테스트를 동시에 실행할 수도 없습니다. 다른 테스트가 완료되거나 실패할 때까지 다음 테스트가 기다립니다.
Test 작성자는 두 번째 실행에서도 올바르게 동작하도록 모든 data를 정확히 초기화하고 정리해야 합니다.
요약과 해설
run_manual.rst:1-100수동 실행은 실제 hardware나 별도 test infrastructure에서 KUnit을 통합할 때 유용합니다. CONFIG_KUNIT과 개별 test option을 켜고 built-in은 boot 때, module은 load 때 실행한 뒤 dmesg의 TAP 결과를 수집합니다.
CONFIG_KUNIT_DEBUGFS를 사용하면 suite별 KTAP 결과를 읽고 boot 뒤 built-in suite를 다시 실행할 수 있습니다. 재실행 가능한 test는 init data에 의존하지 않아야 하고 매 실행마다 state를 초기화·정리해야 하며 동시 실행은 허용되지 않습니다.