 Okay, let's start. Hello, thank you for joining my talk. Today, I would like to explain their extrovert configuration. So let me introduce myself at first. I'm Masami Hiramatsu, work for RINARO as a senior tech lead for RINARO members' learning team. In the RINICS kernel development, I'm responsible for their K-Pro's boot config and its related pressing features and tools. Okay, so let's start today's talk. Here is today's azindar. Let me start from the kernel command line. The kernel command line is, as you know, the boot options of the kernel. It's a way to pass the boot options to the kernel. It passed a long string of the options, and it will be passed in the first in the early stage of the Linux kernel boot. The implementations of the kernel command line depends on their architecture because their boot protocol are different. On the x86, for example, it passed over the memory area, but on the ARM64, it used the device tree. So the kernel command line has some limitations. We have size and coding limitations. Most of their arch support focus by the command line. But there must be single line options. The forker byte may be enough long, but forker byte single line is hard to read and also write. To solve this limitation, I introduce the extra boot configuration. What is the extra boot configuration? It is a new kernel command line extension. I call it as boot config for short. This boot config is plain ASCII text of the tree-structured key-value list. Something like the sys-control.conf file, but more structured. The boot config will load it with the image when boot. And there are in kernel APIs for that. So, okay, let me explain the extra boot configuration syntax. It consists of simple key-value set. At least the kernel, the key is dot, at first, sorry, the key is dot connected words. You can consolidate the options for the same module with the same prefix keys. And you can set the value or array values as a comma-spreaded list as below. And some key words can be merged. For example, key dot word one equal value one and key dot value two equal value two. This can be written as key brace word one equal value one and word two equal value two and brace cross. So, here are the value assignment operators. We have three assignment operators. The equal defines the value of the key. And column equal, it overwrite the previous assignment. For example, key equal value and key column equal bar is key equal bar. And plus equal, append the value as an array element. For example, key equal foo and the key plus equal bar is same as the key equal foo compare. So, this is the latest update of the root config syntax. We can mix the keys and value on the same key. For parent key, we can have our value and sub keys. As below, yeah. However, note that you cannot merge value and sub key by brace. Because it cannot identify a value is a key or value. This is an important syntax, the comment. You can add the comments on the root config. If you put a comment, you can remember why that is said. So, the root config can expand the kernel command line. If the key start from the kernel keyword, those are passed to the kernel command line. This example shows that the root partition command line option. So, that's the kernel.root equal uuid, blah, blah, blah. This root equal uuid will be passed to the kernel command line. Also, the key started from init passed to the kernel command line. But after double dash, this means that these are passed to init process. For example, systemd or something like that. And this example shows that the splash and required option will be passed to the systemd. However, note these are automatically copied to the proc command line. So, if you set up those options, you can find that under the proc command line, too. Okay, here is the example command line. It is very long and hard to read. Yeah, but if you use the root config, this will be written like this. So, compared with the command line, you can easily understand what is set and why. Because there is a command, commands, and each, let's say, options, let's say, listed for each line. And some command, some options are consolidated with the brace. Okay, let's see, let's see more example. So, here is another example of the boot config. That is the boot time tracing. The boot time tracing is natively supporting the boot config. So, its option doesn't start from kernel nor init, but it starts from ftrace. So, this shows an example of the making histogram of init call functions. Usually, histogram tracing needs a long command, but as you can see that the boot config allows us to write it by your structured style, and it is easy to read. So, here is the result of the histogram. You can see the function name and errors time, and those are sorted by the time. So, how we can pass the boot config to the kernel? As I said before, boot config file will be loaded with IntelD. So, here is a boot config command under tools boot config. That can handle the IntelD operation. So, for example, hyphen A option will append your boot config file to init all the image, and hyphen D option can delete it. However, if you pass that the init file, init-od file to the boot config, you can check that the current applied boot config file. And also, if you pass that the boot config file to boot config command, it reformat the boot config file to key value list. So, this shows how the boot config file is appended to the init-od image. That is appended to the init-od with a footer, so kernel will check that the footer to decode it. Note that you need to set the boot config kernel command line option for enable it. Or if you are not specified that this boot config command line option, the kernel will ignore even if there is a boot config in the tail of the IntelD image. So, here it shows that the procfs interface, the boot config supports the procfs interface. So, when you boot up the kernel with boot config, you can see that what boot config is applied via proc-boot config like this. This is a key value list because it is easier to be handled by a share script. Okay, so here is today's summary. I explained the extra boot configuration. It's a new way to pass the boot parameter to Linux with structured key value list. It's a commentable configuration file and it can be used complementarily with kernel command line. So, in the future work, I would like to integrate the boot config command with the init-od. So, if there is a default boot config, mkmint-od will automatically call the boot config command and apply it to our new init-od. Okay, for more information, please read the kernel documentation. And if you have any questions, please ask me on the LKML email. Okay, thank you very much for joining my session. I hope you have a great day. Thank you.