PageSourceSearch

https://docs-tockosorg.netlify.app/src/kernel/lib.rs

html docs-tockosorg.netlify.app collected 2026-10-03 10:39:35 UTC 21,070 bytes, 203 lines download raw bytes

1<!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1.0"><meta name="generator" content="rustdoc"><meta name="description" content="Source of the Rust file `kernel/src/lib.rs`."><title>lib.rs - source</title>
1<script>if(window.location.protocol!=="file:")document.head.insertAdjacentHTML("beforeend","SourceSerif4-Regular-6b053e98.ttf.woff2,FiraSans-Italic-81dc35de.woff2,FiraSans-Regular-0fe48ade.woff2,FiraSans-MediumItalic-ccf7e434.woff2,FiraSans-Medium-e1aa3f0a.woff2,SourceCodePro-Regular-8badfe75.ttf.woff2,SourceCodePro-Semibold-aa29a496.ttf.woff2".split(",").map(f=>`<link rel="preload" as="font" type="font/woff2"href="../../static.files/${f}">`).join(""))</script>
1<link rel="stylesheet" href="../../static.files/normalize-9960930a.css"><link rel="stylesheet" href="../../static.files/rustdoc-ddecd707.css"><meta name="rustdoc-vars" data-root-path="../../" data-static-root-path="../../static.files/" data-current-crate="kernel" data-themes="" data-resource-suffix="" data-rustdoc-version="1.99.0-nightly (87e5904f5 2026-07-20)" data-channel="nightly" data-search-js="search-cf4fc35e.js" data-stringdex-js="stringdex-b5109af9.js" data-settings-js="settings-170eb4bf.js" >
1<script src="../../static.files/storage-41dd4d93.js"></script>
1<script defer src="../../static.files/src-script-813739b1.js"></script>
1<script defer src="../../src-files.js"></script>
1<script defer src="../../static.files/main-417ebf0a.js"></script>
1<noscript><link rel="stylesheet" href="../../static.files/noscript-f7c3ffd8.css"></noscript><link rel="alternate icon" type="image/png" href="../../static.files/favicon-32x32-eab170b8.png"><link rel="icon" type="image/svg+xml" href="../../static.files/favicon-044be391.svg"></head><body class="rustdoc src"><a class="skip-main-content" href="#main-content">Skip to main content</a><!--[if lte IE 11]><div class="warning">This old browser is unsupported and will most likely display funky things.</div><![endif]--><nav class="sidebar"><div class="src-sidebar-title"><h2>Files</h2></div></nav><div class="sidebar-resizer" title="Drag to resize sidebar"></div><main><section id="main-content" class="content" tabindex="-1"><div class="main-heading"><h1><div class="sub-heading">kernel/</div>lib.rs</h1><rustdoc-toolbar></rustdoc-toolbar></div><div class="example-wrap digits-3"><pre class="rust"><code><a href=#1 id=1 data-nosnippet>1</a><span class="comment">// Licensed under the Apache License, Version 2.0 or the MIT License.
2<a href=#2 id=2 data-nosnippet>2</a>// SPDX-License-Identifier: Apache-2.0 OR MIT
3<a href=#3 id=3 data-nosnippet>3</a>// Copyright Tock Contributors 2022.
4<a href=#4 id=4 data-nosnippet>4</a>
5<a href=#5 id=5 data-nosnippet>5</a></span><span class="doccomment">//! Core Tock Kernel
6<a href=#6 id=6 data-nosnippet>6</a>//!
7<a href=#7 id=7 data-nosnippet>7</a>//! The kernel crate implements the core features of Tock as well as shared
8<a href=#8 id=8 data-nosnippet>8</a>//! code that many chips, capsules, and boards use. It also holds the Hardware
9<a href=#9 id=9 data-nosnippet>9</a>//! Interface Layer (HIL) definitions.
10<a href=#10 id=10 data-nosnippet>10</a>//!
11<a href=#11 id=11 data-nosnippet>11</a>//! Most `unsafe` code is in this kernel crate.
12<a href=#12 id=12 data-nosnippet>12</a>//!
13<a href=#13 id=13 data-nosnippet>13</a>//!
14<a href=#14 id=14 data-nosnippet>14</a>//! ## Core Kernel Visibility
15<a href=#15 id=15 data-nosnippet>15</a>//!
16<a href=#16 id=16 data-nosnippet>16</a>//! As the root crate in the Tock operating system, this crate serves multiple
17<a href=#17 id=17 data-nosnippet>17</a>//! purposes:
18<a href=#18 id=18 data-nosnippet>18</a>//!
19<a href=#19 id=19 data-nosnippet>19</a>//! 1. It includes the logic for the core kernel, including process management,
20<a href=#20 id=20 data-nosnippet>20</a>//!    grants, scheduling, etc.
21<a href=#21 id=21 data-nosnippet>21</a>//!
22<a href=#22 id=22 data-nosnippet>22</a>//! 2. It includes important interfaces for hardware and other device
23<a href=#23 id=23 data-nosnippet>23</a>//!    abstractions. These are generally in the HIL and platform folders.
24<a href=#24 id=24 data-nosnippet>24</a>//!
25<a href=#25 id=25 data-nosnippet>25</a>//! 3. It includes utility functions used elsewhere in the kernel, generally by
26<a href=#26 id=26 data-nosnippet>26</a>//!    multiple different crates such that it makes sense to have shared
27<a href=#27 id=27 data-nosnippet>27</a>//!    implementations in the core kernel crate.
28<a href=#28 id=28 data-nosnippet>28</a>//!
29<a href=#29 id=29 data-nosnippet>29</a>//! Because of these different features of the core kernel, managing visibility
30<a href=#30 id=30 data-nosnippet>30</a>//! of the various objects and functions is a bit tricky. In general, the kernel
31<a href=#31 id=31 data-nosnippet>31</a>//! crate only exposes what it absolutely needs to. However, there are three
32<a href=#32 id=32 data-nosnippet>32</a>//! cases where resources in this crate _must_ be exposed.
33<a href=#33 id=33 data-nosnippet>33</a>//!
34<a href=#34 id=34 data-nosnippet>34</a>//! 1. The shared utility functions and structs must be exposed. These are
35<a href=#35 id=35 data-nosnippet>35</a>//!    marked `pub` and are used by many other kernel crates.
36<a href=#36 id=36 data-nosnippet>36</a>//!
37<a href=#37 id=37 data-nosnippet>37</a>//!    Some utility objects and abstractions, however, expose memory unsafe
38<a href=#38 id=38 data-nosnippet>38</a>//!    behavior. These are marked as `unsafe`, and require an `unsafe` block to
39<a href=#39 id=39 data-nosnippet>39</a>//!    use them. One example of this is `StaticRef` which is used for accessing
40<a href=#40 id=40 data-nosnippet>40</a>//!    memory-mapped I/O registers. Since accessing the addresses through just a
41<a href=#41 id=41 data-nosnippet>41</a>//!    memory address is potentially very unsafe, instantiating a `StaticRef`
42<a href=#42 id=42 data-nosnippet>42</a>//!    requires an `unsafe` block.
43<a href=#43 id=43 data-nosnippet>43</a>//!
44<a href=#44 id=44 data-nosnippet>44</a>//! 2. The core kernel types generally have to be exposed as other layers of the
45<a href=#45 id=45 data-nosnippet>45</a>//!    OS need to use them. However, generally only a very small interface is
46<a href=#46 id=46 data-nosnippet>46</a>//!    exposed, and using that interface cannot compromise the overall system or
47<a href=#47 id=47 data-nosnippet>47</a>//!    the core kernel. These functions are also marked `pub`. For example, the
48<a href=#48 id=48 data-nosnippet>48</a>//!    `ProcessBuffer` abstraction must be exposed to capsules to use shared memory
49<a href=#49 id=49 data-nosnippet>49</a>//!    between a process and the kernel. However, the constructor is not public,
50<a href=#50 id=50 data-nosnippet>50</a>//!    and the API exposed to capsules is very limited and confined by the Rust
51<a href=#51 id=51 data-nosnippet>51</a>//!    type system. The constructor and other sensitive interfaces are
52<a href=#52 id=52 data-nosnippet>52</a>//!    restricted to use only inside the kernel crate and are marked
53<a href=#53 id=53 data-nosnippet>53</a>//!    `pub(crate)`.
54<a href=#54 id=54 data-nosnippet>54</a>//!
55<a href=#55 id=55 data-nosnippet>55</a>//!    In some cases, more sensitive core kernel interfaces must be exposed. For
56<a href=#56 id=56 data-nosnippet>56</a>//!    example, the kernel exposes a function for starting the main scheduling
57<a href=#57 id=57 data-nosnippet>57</a>//!    loop in the kernel. Since board crates must be able to start this loop
58<a href=#58 id=58 data-nosnippet>58</a>//!    after all initialization is finished, the kernel loop function must be
59<a href=#59 id=59 data-nosnippet>59</a>//!    exposed and marked `pub`. However, this interface is not generally safe
60<a href=#60 id=60 data-nosnippet>60</a>//!    to use, since starting the loop a second time would compromise the
61<a href=#61 id=61 data-nosnippet>61</a>//!    stability of the overall system. It's also not necessarily memory unsafe
62<a href=#62 id=62 data-nosnippet>62</a>//!    to call the start loop function again, so we do not mark it as `unsafe`.
63<a href=#63 id=63 data-nosnippet>63</a>//!    Instead, we require that the caller hold a `Capability` to call the
64<a href=#64 id=64 data-nosnippet>64</a>//!    public but sensitive functions. More information is in `capabilities.rs`.
65<a href=#65 id=65 data-nosnippet>65</a>//!    This allows the kernel crate to still expose functions as public while
66<a href=#66 id=66 data-nosnippet>66</a>//!    restricting their use. Another example of this is the `Grant`
67<a href=#67 id=67 data-nosnippet>67</a>//!    constructor, which must be called outside of the core kernel, but should
68<a href=#68 id=68 data-nosnippet>68</a>//!    not be called except during the board setup.
69<a href=#69 id=69 data-nosnippet>69</a>//!
70<a href=#70 id=70 data-nosnippet>70</a>//! 3. Certain internal core kernel interfaces must also be exposed. These are
71<a href=#71 id=71 data-nosnippet>71</a>//!    needed for extensions of the core kernel that happen to be implemented in
72<a href=#72 id=72 data-nosnippet>72</a>//!    crates outside of the kernel crate. For example, additional
73<a href=#73 id=73 data-nosnippet>73</a>//!    implementations of `Process` may live outside of the kernel crate. To
74<a href=#74 id=74 data-nosnippet>74</a>//!    successfully implement a new `Process` requires access to certain
75<a href=#75 id=75 data-nosnippet>75</a>//!    in-core-kernel APIs, and these must be marked `pub` so that outside
76<a href=#76 id=76 data-nosnippet>76</a>//!    crates can access them.
77<a href=#77 id=77 data-nosnippet>77</a>//!
78<a href=#78 id=78 data-nosnippet>78</a>//!    These interfaces are highly sensitive, so again we require the caller
79<a href=#79 id=79 data-nosnippet>79</a>//!    hold a Capability to call them. This helps restrict their use and makes
80<a href=#80 id=80 data-nosnippet>80</a>//!    it very clear that calling them requires special permissions.
81<a href=#81 id=81 data-nosnippet>81</a>//!    Additionally, to differentiate these interfaces, which are for external
82<a href=#82 id=82 data-nosnippet>82</a>//!    extensions of core kernel functionality, from the other public but
83<a href=#83 id=83 data-nosnippet>83</a>//!    sensitive interfaces (item 2 above), we append the name `_external` to
84<a href=#84 id=84 data-nosnippet>84</a>//!    the function name.
85<a href=#85 id=85 data-nosnippet>85</a>//!
86<a href=#86 id=86 data-nosnippet>86</a>//!    One note is that there are currently very few extensions to the core
87<a href=#87 id=87 data-nosnippet>87</a>//!    kernel that live outside of the kernel crate. That means we have not
88<a href=#88 id=88 data-nosnippet>88</a>//!    necessarily created `_extern` functions for all the interfaces needed for
89<a href=#89 id=89 data-nosnippet>89</a>//!    this use case. It is likely we will have to create new interfaces as new
90<a href=#90 id=90 data-nosnippet>90</a>//!    use cases are discovered.
91<a href=#91 id=91 data-nosnippet>91</a>
92<a href=#92 id=92 data-nosnippet>92</a></span><span class="comment">// `clippy::missing_safety_doc`: Our goal is to apply this in all of Tock,
93<a href=#93 id=93 data-nosnippet>93</a>// but as of September 2026 we are starting with the kernel crate.
94<a href=#94 id=94 data-nosnippet>94</a></span><span class="attr">#![deny(clippy::missing_safety_doc)]
95<a href=#95 id=95 data-nosnippet>95</a></span><span class="comment">
95// `clippy::undocumented_unsafe_blocks`: Our goal is to apply this in all of
96<a href=#96 id=96 data-nosnippet>96</a>// Tock, but as of September 2026 we are starting with the kernel crate.
97<a href=#97 id=97 data-nosnippet>97</a></span><span class="attr">#![deny(clippy::undocumented_unsafe_blocks)]
98<a href=#98 id=98 data-nosnippet>98</a>#![warn(unreachable_pub)]
99<a href=#99 id=99 data-nosnippet>99</a>#![no_std]
100<a href=#100 id=100 data-nosnippet>100</a>
101<a href=#101 id=101 data-nosnippet>101</a></span><span class="doccomment">/// Kernel major version.
102<a href=#102 id=102 data-nosnippet>102</a>///
103<a href=#103 id=103 data-nosnippet>103</a>/// This is compiled with the crate to enable for checking of compatibility with
104<a href=#104 id=104 data-nosnippet>104</a>/// loaded apps. Major, minor and patch version constants are updated during a
105<a href=#105 id=105 data-nosnippet>105</a>/// release.
106<a href=#106 id=106 data-nosnippet>106</a></span><span class="kw">pub const </span>KERNEL_MAJOR_VERSION: u16 = <span class="number">2</span>;
107<a href=#107 id=107 data-nosnippet>107</a><span class="doccomment">/// Kernel minor version.
108<a href=#108 id=108 data-nosnippet>108</a>///
109<a href=#109 id=109 data-nosnippet>109</a>/// This is compiled with the crate to enable for checking of compatibility with
110<a href=#110 id=110 data-nosnippet>110</a>/// loaded apps.
111<a href=#111 id=111 data-nosnippet>111</a></span><span class="kw">pub const </span>KERNEL_MINOR_VERSION: u16 = <span class="number">4</span>;
112<a href=#112 id=112 data-nosnippet>112</a><span class="doccomment">/// Kernel patch version.
113<a href=#113 id=113 data-nosnippet>113</a></span><span class="kw">pub const </span>KERNEL_PATCH_VERSION: u16 = <span class="number">0</span>;
114<a href=#114 id=114 data-nosnippet>114</a><span class="doccomment">/// Kernel in-development version counter.
115<a href=#115 id=115 data-nosnippet>115</a>///
116<a href=#116 id=116 data-nosnippet>116</a>/// Use to distinguish development kernels from release kernels, and can be used
117<a href=#117 id=117 data-nosnippet>117</a>/// to have applications or tools depend on in-development kernel features that
118<a href=#118 id=118 data-nosnippet>118</a>/// are not yet included in any release.
119<a href=#119 id=119 data-nosnippet>119</a>///
120<a href=#120 id=120 data-nosnippet>120</a>/// A value of `0` indicates that this a release, of the version indicated by
121<a href=#121 id=121 data-nosnippet>121</a>/// [`KERNEL_MAJOR_VERSION`], [`KERNEL_MINOR_VERSION`] and
122<a href=#122 id=122 data-nosnippet>122</a>/// [`KERNEL_PATCH_VERSION`].
123<a href=#123 id=123 data-nosnippet>123</a>///
124<a href=#124 id=124 data-nosnippet>124</a>/// A value other than `0` indicates that this is a development revision, before
125<a href=#125 id=125 data-nosnippet>125</a>/// (older than) the next release described by [`KERNEL_MAJOR_VERSION`],
126<a href=#126 id=126 data-nosnippet>126</a>/// [`KERNEL_MINOR_VERSION`] and [`KERNEL_PATCH_VERSION`].
127<a href=#127 id=127 data-nosnippet>127</a></span><span class="kw">pub const </span>KERNEL_PRERELEASE_VERSION: u16 = <span class="number">1</span>;
128<a href=#128 id=128 data-nosnippet>128</a>
129<a href=#129 id=129 data-nosnippet>129</a><span class="doccomment">/// Tock kernel attributes structure for version information.
130<a href=#130 id=130 data-nosnippet>130</a></span><span class="attr">#[repr(C)]
131<a href=#131 id=131 data-nosnippet>131</a></span><span class="kw">struct </span>TockAttributesKernelVersion {
132<a href=#132 id=132 data-nosnippet>132</a>    major: u16,
133<a href=#133 id=133 data-nosnippet>133</a>    minor: u16,
134<a href=#134 id=134 data-nosnippet>134</a>    patch: u16,
135<a href=#135 id=135 data-nosnippet>135</a>    prerelease: u16,
136<a href=#136 id=136 data-nosnippet>136</a>    tlv_type: u16,
137<a href=#137 id=137 data-nosnippet>137</a>    tlv_len: u16,
138<a href=#138 id=138 data-nosnippet>138</a>}
139<a href=#139 id=139 data-nosnippet>139</a>
140<a href=#140 id=140 data-nosnippet>140</a><span class="doccomment">/// Create a data structure which follows the Tock Kernel Attributes format
141<a href=#141 id=141 data-nosnippet>141</a>/// for specifying the version of the Tock kernel.
142<a href=#142 id=142 data-nosnippet>142</a>///
143<a href=#143 id=143 data-nosnippet>143</a>/// More information on kernel attributes is
144<a href=#144 id=144 data-nosnippet>144</a>/// [here](https://book.tockos.org/doc/kernel_attributes.html).
145<a href=#145 id=145 data-nosnippet>145</a>///
146<a href=#146 id=146 data-nosnippet>146</a>/// This is inserted into a specific section (`.tock.attr.kernel_version`) that
147<a href=#147 id=147 data-nosnippet>147</a>/// the linker script includes at the correct location to be included in the
148<a href=#148 id=148 data-nosnippet>148</a>/// attributes.
149<a href=#149 id=149 data-nosnippet>149</a>///
150<a href=#150 id=150 data-nosnippet>150</a>/// This section attribute is only applied when targeting bare-metal
151<a href=#151 id=151 data-nosnippet>151</a>/// (`target_os = "none"`). Host builds (e.g. tests, clippy, doc) use object
152<a href=#152 id=152 data-nosnippet>152</a>/// formats (Mach-O, PE, ...) that reject a bare section name like this,
153<a href=#153 id=153 data-nosnippet>153</a>/// yielding errors such as: `mach-o section specifier requires a segment and
154<a href=#154 id=154 data-nosnippet>154</a>/// section separated by a comma`.
155<a href=#155 id=155 data-nosnippet>155</a></span><span class="attr">#[cfg_attr(target_os = <span class="string">"none"</span>, <span class="kw">unsafe</span>(link_section = <span class="string">".tock.attr.kernel_version"</span>))]
156<a href=#156 id=156 data-nosnippet>156</a>#[used]
157<a href=#157 id=157 data-nosnippet>157</a></span><span class="kw">static </span>TOCK_ATTRIBUTES_KERNEL_VERSION: TockAttributesKernelVersion = TockAttributesKernelVersion {
158<a href=#158 id=158 data-nosnippet>158</a>    major: KERNEL_MAJOR_VERSION,
159<a href=#159 id=159 data-nosnippet>159</a>    minor: KERNEL_MINOR_VERSION,
160<a href=#160 id=160 data-nosnippet>160</a>    patch: KERNEL_PATCH_VERSION,
161<a href=#161 id=161 data-nosnippet>161</a>    prerelease: KERNEL_PRERELEASE_VERSION,
162<a href=#162 id=162 data-nosnippet>162</a>    tlv_type: <span class="number">0x0103</span>,
163<a href=#163 id=163 data-nosnippet>163</a>    tlv_len: <span class="number">8</span>,
164<a href=#164 id=164 data-nosnippet>164</a>};
165<a href=#165 id=165 data-nosnippet>165</a>
166<a href=#166 id=166 data-nosnippet>166</a><span class="kw">pub mod </span>capabilities;
167<a href=#167 id=167 data-nosnippet>167</a><span class="kw">pub mod </span>collections;
168<a href=#168 id=168 data-nosnippet>168</a><span class="kw">pub mod </span>component;
169<a href=#169 id=169 data-nosnippet>169</a><span class="kw">pub mod </span>debug;
170<a href=#170 id=170 data-nosnippet>170</a><span class="kw">pub mod </span>deferred_call;
171<a href=#171 id=171 data-nosnippet>171</a><span class="kw">pub mod </span>dynamic_binary_storage;
172<a href=#172 id=172 data-nosnippet>172</a><span class="kw">pub mod </span>errorcode;
173<a href=#173 id=173 data-nosnippet>173</a><span class="kw">pub mod </span>grant;
174<a href=#174 id=174 data-nosnippet>174</a><span class="kw">pub mod </span>hil;
175<a href=#175 id=175 data-nosnippet>175</a><span class="kw">pub mod </span>introspection;
176<a href=#176 id=176 data-nosnippet>176</a><span class="kw">pub mod </span>ipc;
177<a href=#177 id=177 data-nosnippet>177</a><span class="kw">pub mod </span>platform;
178<a href=#178 id=178 data-nosnippet>178</a><span class="kw">pub mod </span>process;
179<a href=#179 id=179 data-nosnippet>179</a><span class="kw">pub mod </span>process_checker;
180<a href=#180 id=180 data-nosnippet>180</a><span class="kw">pub mod </span>processbuffer;
181<a href=#181 id=181 data-nosnippet>181</a><span class="kw">pub mod </span>scheduler;
182<a href=#182 id=182 data-nosnippet>182</a><span class="kw">pub mod </span>storage_permissions;
183<a href=#183 id=183 data-nosnippet>183</a><span class="kw">pub mod </span>syscall;
184<a href=#184 id=184 data-nosnippet>184</a><span class="kw">pub mod </span>upcall;
185<a href=#185 id=185 data-nosnippet>185</a><span class="kw">pub mod </span>utilities;
186<a href=#186 id=186 data-nosnippet>186</a>
187<a href=#187 id=187 data-nosnippet>187</a><span class="kw">mod </span>config;
188<a href=#188 id=188 data-nosnippet>188</a><span class="kw">mod </span>kernel;
189<a href=#189 id=189 data-nosnippet>189</a><span class="kw">mod </span>memop;
190<a href=#190 id=190 data-nosnippet>190</a><span class="kw">mod </span>process_array;
191<a href=#191 id=191 data-nosnippet>191</a><span class="kw">mod </span>process_binary;
192<a href=#192 id=192 data-nosnippet>192</a><span class="kw">mod </span>process_loading;
193<a href=#193 id=193 data-nosnippet>193</a><span class="kw">mod </span>process_policies;
194<a href=#194 id=194 data-nosnippet>194</a><span class="kw">mod </span>process_printer;
195<a href=#195 id=195 data-nosnippet>195</a><span class="kw">mod </span>process_standard;
196<a href=#196 id=196 data-nosnippet>196</a><span class="kw">mod </span>syscall_driver;
197<a href=#197 id=197 data-nosnippet>197</a>
198<a href=#198 id=198 data-nosnippet>198</a><span class="comment">
198// Core resources exposed as `kernel::Type`.
199<a href=#199 id=199 data-nosnippet>199</a></span><span class="kw">pub use </span><span class="kw">crate</span>::errorcode::ErrorCode;
200<a href=#200 id=200 data-nosnippet>200</a><span class="kw">pub use </span><span class="kw">crate</span>::kernel::Kernel;
201<a href=#201 id=201 data-nosnippet>201</a><span class="kw">pub use </span><span class="kw">crate</span>::process::ProcessId;
202<a href=#202 id=202 data-nosnippet>202</a><span class="kw">pub use </span><span class="kw">crate</span>::scheduler::Scheduler;
203</code></pre></div></section></main></body></html>

Line numbers count LF bytes from the start of the resource, as the search results do. Vendor segments are library code the classifier recognised; they are stored but not indexed. Bytes are shown as Latin1 characters, one per byte.