bootconfig.rst 11 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335
  1. .. SPDX-License-Identifier: GPL-2.0
  2. .. _bootconfig:
  3. ==================
  4. Boot Configuration
  5. ==================
  6. :Author: Masami Hiramatsu <mhiramat@kernel.org>
  7. Overview
  8. ========
  9. The boot configuration expands the current kernel command line to support
  10. additional key-value data when booting the kernel in an efficient way.
  11. This allows administrators to pass a structured-Key config file.
  12. Config File Syntax
  13. ==================
  14. The boot config syntax is a simple structured key-value. Each key consists
  15. of dot-connected-words, and key and value are connected by ``=``. The value
  16. string has to be terminated by the following delimiters described below.
  17. Each key word must contain only alphabets, numbers, dash (``-``) or underscore
  18. (``_``). And each value only contains printable characters or spaces except
  19. for delimiters such as semi-colon (``;``), new-line (``\n``), comma (``,``),
  20. hash (``#``) and closing brace (``}``).
  21. If the ``=`` is followed by whitespace up to one of these delimiters, the
  22. key is assigned an empty value.
  23. For arrays, the array values are comma (``,``) separated, and comments and
  24. line breaks with newline (``\n``) are allowed between array values for
  25. readability. Thus the first entry of the array must be on the same line as
  26. the key.::
  27. KEY[.WORD[...]] = VALUE[, VALUE2[...]][;]
  28. Unlike the kernel command line syntax, white spaces (including tabs) are
  29. ignored around the comma and ``=``.
  30. If you want to use those delimiters in a value, you can use either double-
  31. quotes (``"VALUE"``) or single-quotes (``'VALUE'``) to quote it. Note that
  32. you can not escape these quotes.
  33. There can be a key which doesn't have value or has an empty value. Those keys
  34. are used for checking if the key exists or not (like a boolean).
  35. Key-Value Syntax
  36. ----------------
  37. The boot config file syntax allows user to merge partially same word keys
  38. by brace. For example::
  39. foo.bar.baz = value1
  40. foo.bar.qux.quux = value2
  41. These can be written also in::
  42. foo.bar {
  43. baz = value1
  44. qux.quux = value2
  45. }
  46. Or more shorter, written as following::
  47. foo.bar { baz = value1; qux.quux = value2 }
  48. In both styles, same key words are automatically merged when parsing it
  49. at boot time. So you can append similar trees or key-values.
  50. Same-key Values
  51. ---------------
  52. It is prohibited that two or more values or arrays share a same-key.
  53. For example,::
  54. foo = bar, baz
  55. foo = qux # !ERROR! we can not re-define same key
  56. If you want to update the value, you must use the override operator
  57. ``:=`` explicitly. For example::
  58. foo = bar, baz
  59. foo := qux
  60. then, the ``qux`` is assigned to ``foo`` key. This is useful for
  61. overriding the default value by adding (partial) custom bootconfigs
  62. without parsing the default bootconfig.
  63. If you want to append the value to existing key as an array member,
  64. you can use ``+=`` operator. For example::
  65. foo = bar, baz
  66. foo += qux
  67. In this case, the key ``foo`` has ``bar``, ``baz`` and ``qux``.
  68. Moreover, sub-keys and a value can coexist under a parent key.
  69. For example, following config is allowed.::
  70. foo = value1
  71. foo.bar = value2
  72. foo := value3 # This will update foo's value.
  73. Note, since there is no syntax to put a raw value directly under a
  74. structured key, you have to define it outside of the brace. For example::
  75. foo {
  76. bar = value1
  77. bar {
  78. baz = value2
  79. qux = value3
  80. }
  81. }
  82. Also, the order of the value node under a key is fixed. If there
  83. are a value and subkeys, the value is always the first child node
  84. of the key. Thus if user specifies subkeys first, e.g.::
  85. foo.bar = value1
  86. foo = value2
  87. In the program (and /proc/bootconfig), it will be shown as below::
  88. foo = value2
  89. foo.bar = value1
  90. Comments
  91. --------
  92. The config syntax accepts shell-script style comments. The comments starting
  93. with hash ("#") until newline ("\n") will be ignored.
  94. ::
  95. # comment line
  96. foo = value # value is set to foo.
  97. bar = 1, # 1st element
  98. 2, # 2nd element
  99. 3 # 3rd element
  100. This is parsed as below::
  101. foo = value
  102. bar = 1, 2, 3
  103. Note that you can NOT put a comment or a newline between value and delimiter
  104. (``,`` or ``;``). This means following config has a syntax error ::
  105. key = 1 # comment
  106. ,2
  107. /proc/bootconfig
  108. ================
  109. /proc/bootconfig is a user-space interface of the boot config.
  110. Unlike /proc/cmdline, this file shows the key-value style list.
  111. Each key-value pair is shown in each line with following style::
  112. KEY[.WORDS...] = "[VALUE]"[,"VALUE2"...]
  113. Boot Kernel With a Boot Config
  114. ==============================
  115. There are two options to boot the kernel with bootconfig: attaching the
  116. bootconfig to the initrd image or embedding it in the kernel itself.
  117. Attaching a Boot Config to Initrd
  118. ---------------------------------
  119. Since the boot configuration file is loaded with initrd by default,
  120. it will be added to the end of the initrd (initramfs) image file with
  121. padding, size, checksum and 12-byte magic word as below.
  122. [initrd][bootconfig][padding][size(le32)][checksum(le32)][#BOOTCONFIG\n]
  123. The size and checksum fields are unsigned 32bit little endian value.
  124. When the boot configuration is added to the initrd image, the total
  125. file size is aligned to 4 bytes. To fill the gap, null characters
  126. (``\0``) will be added. Thus the ``size`` is the length of the bootconfig
  127. file + padding bytes.
  128. The Linux kernel decodes the last part of the initrd image in memory to
  129. get the boot configuration data.
  130. Because of this "piggyback" method, there is no need to change or
  131. update the boot loader and the kernel image itself as long as the boot
  132. loader passes the correct initrd file size. If by any chance, the boot
  133. loader passes a longer size, the kernel fails to find the bootconfig data.
  134. To do this operation, Linux kernel provides ``bootconfig`` command under
  135. tools/bootconfig, which allows admin to apply or delete the config file
  136. to/from initrd image. You can build it by the following command::
  137. # make -C tools/bootconfig
  138. To add your boot config file to initrd image, run bootconfig as below
  139. (Old data is removed automatically if exists)::
  140. # tools/bootconfig/bootconfig -a your-config /boot/initrd.img-X.Y.Z
  141. To remove the config from the image, you can use -d option as below::
  142. # tools/bootconfig/bootconfig -d /boot/initrd.img-X.Y.Z
  143. Then add "bootconfig" on the normal kernel command line to tell the
  144. kernel to look for the bootconfig at the end of the initrd file.
  145. Alternatively, build your kernel with the ``CONFIG_BOOT_CONFIG_FORCE``
  146. Kconfig option selected.
  147. Embedding a Boot Config into Kernel
  148. -----------------------------------
  149. If you can not use initrd, you can also embed the bootconfig file in the
  150. kernel by Kconfig options. In this case, you need to recompile the kernel
  151. with the following configs::
  152. CONFIG_BOOT_CONFIG_EMBED=y
  153. CONFIG_BOOT_CONFIG_EMBED_FILE="/PATH/TO/BOOTCONFIG/FILE"
  154. ``CONFIG_BOOT_CONFIG_EMBED_FILE`` requires an absolute path or a relative
  155. path to the bootconfig file from source tree or object tree.
  156. The kernel will embed it as the default bootconfig.
  157. Just as when attaching the bootconfig to the initrd, you need ``bootconfig``
  158. option on the kernel command line to enable the embedded bootconfig, or,
  159. alternatively, build your kernel with the ``CONFIG_BOOT_CONFIG_FORCE``
  160. Kconfig option selected.
  161. Note that even if you set this option, you can override the embedded
  162. bootconfig by another bootconfig which attached to the initrd.
  163. Kernel parameters via Boot Config
  164. =================================
  165. In addition to the kernel command line, the boot config can be used for
  166. passing the kernel parameters. All the key-value pairs under ``kernel``
  167. key will be passed to kernel cmdline directly. Moreover, the key-value
  168. pairs under ``init`` will be passed to init process via the cmdline.
  169. The parameters are concatenated with user-given kernel cmdline string
  170. as the following order, so that the command line parameter can override
  171. bootconfig parameters (this depends on how the subsystem handles parameters
  172. but in general, earlier parameter will be overwritten by later one.)::
  173. [bootconfig params][cmdline params] -- [bootconfig init params][cmdline init params]
  174. Here is an example of the bootconfig file for kernel/init parameters.::
  175. kernel {
  176. root = 01234567-89ab-cdef-0123-456789abcd
  177. }
  178. init {
  179. splash
  180. }
  181. This will be copied into the kernel cmdline string as the following::
  182. root="01234567-89ab-cdef-0123-456789abcd" -- splash
  183. If user gives some other command line like,::
  184. ro bootconfig -- quiet
  185. The final kernel cmdline will be the following::
  186. root="01234567-89ab-cdef-0123-456789abcd" ro bootconfig -- splash quiet
  187. Config File Limitation
  188. ======================
  189. Currently the maximum config size is 32KB and the total key-words (not
  190. key-value entries) must be under 1024 nodes.
  191. Note: this is not the number of entries but nodes, an entry must consume
  192. more than 2 nodes (a key-word and a value). So theoretically, it will be
  193. up to 512 key-value pairs. If keys contains 3 words in average, it can
  194. contain 256 key-value pairs. In most cases, the number of config items
  195. will be under 100 entries and smaller than 8KB, so it would be enough.
  196. If the node number exceeds 1024, parser returns an error even if the file
  197. size is smaller than 32KB. (Note that this maximum size is not including
  198. the padding null characters.)
  199. Anyway, since bootconfig command verifies it when appending a boot config
  200. to initrd image, user can notice it before boot.
  201. Bootconfig APIs
  202. ===============
  203. User can query or loop on key-value pairs, also it is possible to find
  204. a root (prefix) key node and find key-values under that node.
  205. If you have a key string, you can query the value directly with the key
  206. using xbc_find_value(). If you want to know what keys exist in the boot
  207. config, you can use xbc_for_each_key_value() to iterate key-value pairs.
  208. Note that you need to use xbc_array_for_each_value() for accessing
  209. each array's value, e.g.::
  210. vnode = NULL;
  211. xbc_find_value("key.word", &vnode);
  212. if (vnode && xbc_node_is_array(vnode))
  213. xbc_array_for_each_value(vnode, value) {
  214. printk("%s ", value);
  215. }
  216. If you want to focus on keys which have a prefix string, you can use
  217. xbc_find_node() to find a node by the prefix string, and iterate
  218. keys under the prefix node with xbc_node_for_each_key_value().
  219. But the most typical usage is to get the named value under prefix
  220. or get the named array under prefix as below::
  221. root = xbc_find_node("key.prefix");
  222. value = xbc_node_find_value(root, "option", &vnode);
  223. ...
  224. xbc_node_for_each_array_value(root, "array-option", value, anode) {
  225. ...
  226. }
  227. This accesses a value of "key.prefix.option" and an array of
  228. "key.prefix.array-option".
  229. Locking is not needed, since after initialization, the config becomes
  230. read-only. All data and keys must be copied if you need to modify it.
  231. Functions and structures
  232. ========================
  233. .. kernel-doc:: include/linux/bootconfig.h
  234. .. kernel-doc:: lib/bootconfig.c