On Sun, Aug 25, 2019 at 10:15 PM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote:
>
> Supplemental kernel command line (SKC) allows admin to pass a
> tree-structured supplemental kernel commandline file (SKC file)
> when boot up kernel. This expands the kernel command line in
> efficient way.
>
> SKC file will contain some key-value commands, e.g.
>
> key.word = value1;
> another.key.word = value2;
>
> It can fold same keys with braces, also you can write array
> data. For example,
>
> key {
> word1 {
> setting1 = data;
> setting2;
> }
> word2.array = "val1", "val2";
> }
Why invent a custom file format? You could use YAML (or JSON):
key:
word1:
setting1: data
setting2: true
word2:
- val1
- val2
That would allow you to define a schema for defined options and can
easily be manipulated with python (or any language with dictionaries
and lists). That does imply adding a YAML parser to the kernel which
I'm not sure is a great idea. There is a C parser lib, but working
with YAML in C is not that great compared to python.
Another option would be using the DTS format, but as a separate file.
That's not unprecedented as u-boot FIT image is a DTB. Then the kernel
already has the parser. And you could still have schema now.
A new interface will take a lot of bootloader work to make it easy to
use given the user has to manually load some file in the bootloader
and know a good address to load it to. Between that and rebuilding the
kernel with the configuration, I'd pick rebuilding the kernel. Perhaps
this version will highlight that the original proposal was not so bad.
Another thought, maybe you could process the configuration file that's
in a readable/editable format into a flat representation that could
simply be added to the kernel command line:
key.word1.setting1=data key.word1.setting2 key.word2=val1,val2
That would then use an existing interface and probably simplify the
kernel parsing.
Rob
