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.