Update translated documentation (#1408)

This commit is contained in:
github-actions[bot] 2025-11-26 00:06:31 +08:00 committed by GitHub
parent 9420fe09cd
commit a69dad1bb2
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 18 additions and 19 deletions

View File

@ -294,7 +294,7 @@
"hash": "52df04d6a276b42617f7b79bbbffa61e"
},
"en:kernel/ktest/gvisor_syscall_test.rst": {
"hash": "bfa0b1f0bcb791573c73670df23cbb32"
"hash": "60cc96606ccd50bb3e669b378693b742"
},
"en:kernel/syscall/sys_capget_capset.md": {
"hash": "f3b86c00e9f28df5c0e6c15905e53907"

View File

@ -4,7 +4,7 @@
- Source document: kernel/ktest/gvisor_syscall_test.rst
- Translation time: 2025-10-09 14:36:26
- Translation time: 2025-11-25 16:01:36
- Translation model: `hunyuan-turbos-latest`
@ -20,26 +20,26 @@ DragonOS integrates the gVisor system call test suite to verify the compatibilit
Overview
========
gVisor is a container runtime sandbox developed by Google, which includes a comprehensive set of system call compatibility tests. These tests are designed to validate whether an operating system's system call implementation complies with Linux standards.
gVisor is a container runtime sandbox developed by Google, which includes a comprehensive set of system call compatibility tests. These tests are designed to validate whether an operating system's system call implementations comply with Linux standards.
Key Features:
- **Comprehensive Test Coverage**: Contains hundreds of system call test cases
- **Whitelist Mechanism**: By default, only verified tests are executed, with support gradually expanding
- **Blacklist Filtering**: Allows blocking specific test cases for each test program
- **Automated Execution**: Provides Makefile and scripts to simplify the testing process
- **Automated Execution**: Provides Makefiles and scripts to simplify the testing process
Automated Testing
==========
Execute the `make test-syscall` command. This command will launch DragonOS and automatically execute the gvisor syscall test suite. After testing completes, it will exit qemu. The return status will be success or failure based on the test case success rate - returning failure if the success rate is not 100%. The execution flow of this command is as follows:
Execute the `make test-syscall` command. This command will launch DragonOS and automatically execute the gvisor syscall test suite. After testing completes, it will exit qemu. The command will return success or failure based on the test case success rate - returning failure if the success rate is not 100%. The execution flow of this command is as follows:
1. Execute the configuration in `enable_compile_gvisor.sh` comment `app-blocklist.toml` regarding blocking the gvisor test suite
1. Execute `toggle_compile_gvisor.sh enable` to comment out the gvisor test suite-related blocking configurations in `app-blocklist.toml`
2. Compile DragonOS
3. Write the image
4. Start DragonOS in qemu background mode (without graphics), while setting environment variables `AUTO_TEST` (auto-test option, currently only supports syscall testing) and `SYSCALL_TEST_DIR` (test suite directory). These environment variables will be passed to DragonOS as command-line parameters. Then when the busybox init process executes the rcS script, this script will execute the corresponding test through the `AUTO_TEST` option
5. Execute `monitor_test_results.sh` to periodically check the qemu serial output content and determine success or failure return based on test results
6. Execute `disable_compile_gvisor.sh` to uncomment the configuration in `app-blocklist.toml` regarding blocking the gvisor test suite
4. Start DragonOS in the background in qemu's non-graphical mode, while setting environment variables `AUTO_TEST` (auto-test option, currently only supports syscall testing) and `SYSCALL_TEST_DIR` (directory where the test suite is located). These two environment variables will be passed to DragonOS as command-line parameters. Then, when the busybox init process executes the rcS script, this script will execute the corresponding tests through the `AUTO_TEST` option
5. Execute `monitor_test_results.sh` to periodically check the qemu serial port output content and determine whether to return success or failure based on the test results
6. Execute `toggle_compile_gvisor.sh disable` to uncomment the relevant configurations in `app-blocklist.toml`, restoring the default blocking state
The corresponding workflow configuration file is `test-x86.yml`
@ -52,22 +52,21 @@ Manual Testing
cd user/apps/tests/syscall/gvisor
2. Run whitelist tests on Linux (automatically downloads the test suite):
2. Run whitelist tests in Linux (automatically downloads the test suite):
.. code-block:: bash
make test
3. If you need to run tests, first modify the configuration file:
3. If you need to run tests, you can quickly modify configurations via scripts:
Edit `config/app-blocklist.toml`, and comment out the following content:
.. code-block:: bash
.. code-block:: toml
# Enable gVisor testing (comment out blocklist configurations)
bash user/apps/tests/syscall/gvisor/toggle_compile_gvisor.sh enable
# Block gvisor system call tests
# [[blocked_apps]]
# name = "gvisor syscall tests"
# reason = "Blocked due to large file size. To allow system call tests, uncomment these lines"
# Restore default blocking after testing
bash user/apps/tests/syscall/gvisor/toggle_compile_gvisor.sh disable
4. Run tests within the DragonOS system:
@ -90,12 +89,12 @@ Testing Mechanism
Whitelist Mode
-----------
The test framework enables whitelist mode by default, running only the test programs specified in `_translated_label__`whitelist.txt`_en`. This allows for gradual verification of DragonOS's system call implementations.
The test framework enables whitelist mode by default, running only the test programs specified in `_translated_label__`whitelist.txt`_en`. This allows for gradual validation of DragonOS's system call implementations.
Blacklist Filtering
-----------
For each test program, specific test cases can be blocked through files in the `_translated_label__`blocklists/`_en` directory. This is particularly useful for skipping unsupported or unstable tests.
For each test program, specific test cases can be blocked through files in the `_translated_label__`blocklists/`_en` directory. This is particularly useful for skipping tests that are not yet supported or are unstable.
More Detailed Information
==============