From: Masami Hiramatsu <mhiramat@kernel.org>
To: Rob Herring <robh+dt@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Frank Rowand <frowand.list@gmail.com>,
Ingo Molnar <mingo@redhat.com>,
Namhyung Kim <namhyung@kernel.org>, Tim Bird <Tim.Bird@sony.com>,
Jiri Olsa <jolsa@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Tom Zanussi <tom.zanussi@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Alexey Dobriyan <adobriyan@gmail.com>,
Jonathan Corbet <corbet@lwn.net>,
Linus Torvalds <torvalds@linux-foundation.org>,
Linux Doc Mailing List <linux-doc@vger.kernel.org>,
linux-fsdevel@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH v3 01/19] skc: Add supplemental kernel cmdline support
Date: Tue, 27 Aug 2019 11:37:24 +0900 [thread overview]
Message-ID: <20190827113724.fa32ce580f5901004044d0f1@kernel.org> (raw)
In-Reply-To: <CAL_Jsq+Pm4D_fm+iG9UfGSObx2fSXshZuMW4QKwGePbg4RUEjA@mail.gmail.com>
Hi Rob,
Thank you for your comment!
On Mon, 26 Aug 2019 08:27:48 -0500
Rob Herring <robh+dt@kernel.org> wrote:
> On Sun, Aug 25, 2019 at 10:15 PM Masami Hiramatsu <mhiramat@kernel.org> 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):
Yeah, actually my early idea was using JSON, since it is widely used and
many good tools. However, I thought that is not human friendly format :(.
I would like to give an easy to read/write but structured interface.
>
> key:
> word1:
> setting1: data
> setting2: true
> word2:
> - val1
> - val2
(Ah, in above example "array" is just a part of key, and is not
a reserved word.)
> 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.
Yes, using plain YAML maybe requires user-space coverter to some
other format.
>
> 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.
Yeah, that is what I consider at first. I discussed it with Frank at
OSSJ, but he suggested to not use DTS, nor touch current parser in kernel.
So I finally convinced not using DTS.
> 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.
Right, that is what I have to do next if this is accepted. As I shown, I
modified Qemu and Grub. (Since U-Boot is very flexible, it is easy to
load skc file and modify bootargs by manual.)
What I found was, since the bootloaders already supported loading DTB,
it would not be so hard to add loading another file :) (curiously, the
most complicated part was modifying kernel cmdline)
> 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.
Maybe for embedded, yes. For admins who use vendor kernel, no.
> 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:
(BTW, it is easy to make a flat representation data as you can see
in /proc/sup_cmdline, which is added by [2/19])
>
> key.word1.setting1=data key.word1.setting2 key.word2=val1,val2
>
> That would then use an existing interface and probably simplify the
> kernel parsing.
Hmm, if it is just for passing extended arguments, that will be enough
(that was my first version of SKC, here
https://github.com/mhiramat/skc/tree/5f0429c244d1c9f8f84711bc33e1e6f90df62df8 )
But I found that was not enough flexible for my usage. For expressing
complex ftrace settings (e.g. nesting options, some options related to
other options etc.), I need tree-structured data, something like Devicetree.
Thank you,
--
Masami Hiramatsu <mhiramat@kernel.org>
next prev parent reply other threads:[~2019-08-27 2:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-26 3:15 [RFC PATCH v3 00/19] tracing: skc: Boot-time tracing and Supplemental Kernel Cmdline Masami Hiramatsu
2019-08-26 3:15 ` [RFC PATCH v3 01/19] skc: Add supplemental kernel cmdline support Masami Hiramatsu
2019-08-26 13:27 ` Rob Herring
2019-08-27 2:37 ` Masami Hiramatsu [this message]
2019-08-26 3:16 ` [RFC PATCH v3 02/19] skc: Add /proc/sup_cmdline to show SKC key-value list Masami Hiramatsu
2019-08-26 3:16 ` [RFC PATCH v3 03/19] skc: Add a boot setup routine from cmdline Masami Hiramatsu
2019-08-26 3:16 ` [RFC PATCH v3 04/19] Documentation: skc: Add a doc for supplemental kernel cmdline Masami Hiramatsu
2019-08-26 3:16 ` [RFC PATCH v3 05/19] tracing: Apply soft-disabled and filter to tracepoints printk Masami Hiramatsu
2019-08-26 3:16 ` [RFC PATCH v3 06/19] tracing: kprobes: Output kprobe event to printk buffer Masami Hiramatsu
2019-08-26 3:17 ` [RFC PATCH v3 07/19] tracing: Expose EXPORT_SYMBOL_GPL symbol Masami Hiramatsu
2019-08-26 3:17 ` [RFC PATCH v3 08/19] tracing: kprobes: Register to dynevent earlier stage Masami Hiramatsu
2019-08-26 3:17 ` [RFC PATCH v3 09/19] tracing: Accept different type for synthetic event fields Masami Hiramatsu
2019-08-26 3:17 ` [RFC PATCH v3 10/19] tracing: Add NULL trace-array check in print_synth_event() Masami Hiramatsu
2019-08-26 3:17 ` [RFC PATCH v3 11/19] tracing/boot: Add boot-time tracing by supplemental kernel cmdline Masami Hiramatsu
2019-08-26 3:18 ` [RFC PATCH v3 12/19] tracing/boot: Add per-event settings Masami Hiramatsu
2019-08-26 3:18 ` [RFC PATCH v3 13/19] tracing/boot Add kprobe event support Masami Hiramatsu
2019-08-26 3:18 ` [RFC PATCH v3 14/19] tracing/boot: Add synthetic " Masami Hiramatsu
2019-08-26 3:18 ` [RFC PATCH v3 15/19] tracing/boot: Add instance node support Masami Hiramatsu
2019-08-26 3:18 ` [RFC PATCH v3 16/19] tracing/boot: Add cpu_mask option support Masami Hiramatsu
2019-08-26 3:18 ` [RFC PATCH v3 17/19] tracing/boot: Add function tracer filter options Masami Hiramatsu
2019-08-26 3:19 ` [RFC PATCH v3 18/19] tracing/boot: Add function-graph tracer options Masami Hiramatsu
2019-08-26 3:19 ` [RFC PATCH v3 19/19] Documentation: tracing: Add boot-time tracing document Masami Hiramatsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190827113724.fa32ce580f5901004044d0f1@kernel.org \
--to=mhiramat@kernel.org \
--cc=Tim.Bird@sony.com \
--cc=acme@kernel.org \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jolsa@redhat.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=robh+dt@kernel.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=tom.zanussi@linux.intel.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).