7:24 a.m.
Hi Kairui,
On Fri, 29 Apr 2022 23:29:55 +0800
Kairui Song <ryncsn(a)gmail.com> wrote:
[...]
> hmm... in the end KDUMP_COMMANDLINE_APPEND is set for every
(supported)
> arch. So having a "default" set in the template currently doesn't
make
> much sense. Furthermore the command line has quite a few common entries
> between the arches. So how about splitting update_param into two
> functions param_add and param_remove that add remove the given params
> from the default set in the template. With that I hope it will be easier
> to see the differences between the arches.
Hi Philipp,
After trying this idea, I found it rather difficult to implement these
helpers...
The problem is that regex/sed is not enough to parse arguments, so
something like xargs is needed to parse the args. For example, parsing
dracut_args which may contain quoted string, and kernel cmdline
(KDUMP_COMMANDLINE) also allow quoted strings.
And since we want to use this script for both sysconfig and
kdump.conf, which introduces a lot more corner cases (matching word
borders correctly, avoiding redundant space after removing a param,
etc... ) and the code ends up really complex. Not sure worth
maintaining a long chunk of code just for generating simple config
files.
And think again, maybe a whole line replacement like setting whole
KDUMP_COMMANDLINE_APPEND, for every arch, is not that hard to read,
maybe not harder than calling param_add/update/del repeatedly. And the
logic of the config and the script is much simpler to understand, and
to maintain.
What do you think?
You've got some very good points here...
An other problem I noticed while thinking about this is that when we
use one generator for multiple configs it most likely will get quite
messy. What I mean is that we then have multiple places (the configs
plus the generator) we need to check every time we update an option. My
fear is that this will be forgotten from time to time resulting in
unnecessary bugs we need to handle. Ideally we find a way such that a
config is defined in just one place.
So how about this? We have one <config>-generator script for each config
we want to generate. The <config>-generator is basically what you
suggested except, that it also contains the current .config file in a
here-doc. With that one config is completely handled in one place. The
only downside is that there is a little bit of duplicate code but I
think that is acceptable.
What do you think?
Thanks
Philipp