1.. SPDX-License-Identifier: GPL-2.0 2 3General Information 4=================== 5 6This document contains useful information to know when working with 7the Rust support in the kernel. 8 9 10Code documentation 11------------------ 12 13Rust kernel code is documented using ``rustdoc``, its built-in documentation 14generator. 15 16The generated HTML docs include integrated search, linked items (e.g. types, 17functions, constants), source code, etc. They may be read at (TODO: link when 18in mainline and generated alongside the rest of the documentation): 19 20 http://kernel.org/ 21 22The docs can also be easily generated and read locally. This is quite fast 23(same order as compiling the code itself) and no special tools or environment 24are needed. This has the added advantage that they will be tailored to 25the particular kernel configuration used. To generate them, use the ``rustdoc`` 26target with the same invocation used for compilation, e.g.:: 27 28 make LLVM=1 rustdoc 29 30To read the docs locally in your web browser, run e.g.:: 31 32 xdg-open Documentation/output/rust/rustdoc/kernel/index.html 33 34To learn about how to write the documentation, please see coding-guidelines.rst. 35 36 37Extra lints 38----------- 39 40While ``rustc`` is a very helpful compiler, some extra lints and analyses are 41available via ``clippy``, a Rust linter. To enable it, pass ``CLIPPY=1`` to 42the same invocation used for compilation, e.g.:: 43 44 make LLVM=1 CLIPPY=1 45 46Please note that Clippy may change code generation, thus it should not be 47enabled while building a production kernel. 48 49 50Abstractions vs. bindings 51------------------------- 52 53Abstractions are Rust code wrapping kernel functionality from the C side. 54 55In order to use functions and types from the C side, bindings are created. 56Bindings are the declarations for Rust of those functions and types from 57the C side. 58 59For instance, one may write a ``Mutex`` abstraction in Rust which wraps 60a ``struct mutex`` from the C side and calls its functions through the bindings. 61 62Abstractions are not available for all the kernel internal APIs and concepts, 63but it is intended that coverage is expanded as time goes on. "Leaf" modules 64(e.g. drivers) should not use the C bindings directly. Instead, subsystems 65should provide as-safe-as-possible abstractions as needed. 66 67 68Conditional compilation 69----------------------- 70 71Rust code has access to conditional compilation based on the kernel 72configuration: 73 74.. code-block:: rust 75 76 #[cfg(CONFIG_X)] // Enabled (`y` or `m`) 77 #[cfg(CONFIG_X="y")] // Enabled as a built-in (`y`) 78 #[cfg(CONFIG_X="m")] // Enabled as a module (`m`) 79 #[cfg(not(CONFIG_X))] // Disabled 80 81 82Testing 83------- 84 85There are the tests that come from the examples in the Rust documentation 86and get transformed into KUnit tests. These can be run via KUnit. For example 87via ``kunit_tool`` (``kunit.py``) on the command line:: 88 89 ./tools/testing/kunit/kunit.py run --make_options LLVM=1 --arch x86_64 --kconfig_add CONFIG_RUST=y 90 91Alternatively, KUnit can run them as kernel built-in at boot. Refer to 92Documentation/dev-tools/kunit/index.rst for the general KUnit documentation 93and Documentation/dev-tools/kunit/architecture.rst for the details of kernel 94built-in vs. command line testing. 95 96Additionally, there are the ``#[test]`` tests. These can be run using 97the ``rusttest`` Make target:: 98 99 make LLVM=1 rusttest 100 101This requires the kernel ``.config`` and downloads external repositories. 102It runs the ``#[test]`` tests on the host (currently) and thus is fairly 103limited in what these tests can test. 104