xref: /linux/Documentation/rust/general-information.rst (revision daa121128a2d2ac6006159e2c47676e4fcd21eab)
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.. code-block::
68
69	                                                rust/bindings/
70	                                               (rust/helpers.c)
71
72	                                                   include/ -----+ <-+
73	                                                                 |   |
74	  drivers/              rust/kernel/              +----------+ <-+   |
75	    fs/                                           | bindgen  |       |
76	   .../            +-------------------+          +----------+ --+   |
77	                   |    Abstractions   |                         |   |
78	+---------+        | +------+ +------+ |          +----------+   |   |
79	| my_foo  | -----> | | foo  | | bar  | | -------> | Bindings | <-+   |
80	| driver  |  Safe  | | sub- | | sub- | |  Unsafe  |          |       |
81	+---------+        | |system| |system| |          | bindings | <-----+
82	     |             | +------+ +------+ |          |  crate   |       |
83	     |             |   kernel crate    |          +----------+       |
84	     |             +-------------------+                             |
85	     |                                                               |
86	     +------------------# FORBIDDEN #--------------------------------+
87
88The main idea is to encapsulate all direct interaction with the kernel's C APIs
89into carefully reviewed and documented abstractions. Then users of these
90abstractions cannot introduce undefined behavior (UB) as long as:
91
92#. The abstractions are correct ("sound").
93#. Any ``unsafe`` blocks respect the safety contract necessary to call the
94   operations inside the block. Similarly, any ``unsafe impl``\ s respect the
95   safety contract necessary to implement the trait.
96
97Bindings
98~~~~~~~~
99
100By including a C header from ``include/`` into
101``rust/bindings/bindings_helper.h``, the ``bindgen`` tool will auto-generate the
102bindings for the included subsystem. After building, see the ``*_generated.rs``
103output files in the ``rust/bindings/`` directory.
104
105For parts of the C header that ``bindgen`` does not auto generate, e.g. C
106``inline`` functions or non-trivial macros, it is acceptable to add a small
107wrapper function to ``rust/helpers.c`` to make it available for the Rust side as
108well.
109
110Abstractions
111~~~~~~~~~~~~
112
113Abstractions are the layer between the bindings and the in-kernel users. They
114are located in ``rust/kernel/`` and their role is to encapsulate the unsafe
115access to the bindings into an as-safe-as-possible API that they expose to their
116users. Users of the abstractions include things like drivers or file systems
117written in Rust.
118
119Besides the safety aspect, the abstractions are supposed to be "ergonomic", in
120the sense that they turn the C interfaces into "idiomatic" Rust code. Basic
121examples are to turn the C resource acquisition and release into Rust
122constructors and destructors or C integer error codes into Rust's ``Result``\ s.
123
124
125Conditional compilation
126-----------------------
127
128Rust code has access to conditional compilation based on the kernel
129configuration:
130
131.. code-block:: rust
132
133	#[cfg(CONFIG_X)]       // Enabled               (`y` or `m`)
134	#[cfg(CONFIG_X="y")]   // Enabled as a built-in (`y`)
135	#[cfg(CONFIG_X="m")]   // Enabled as a module   (`m`)
136	#[cfg(not(CONFIG_X))]  // Disabled
137