[PATCH] env: Allow string CONFIG options in the text environment

[Holger Brunck]

Hi Tom,

> > > On Fri, 4 Nov 2022 at 08:20, Holger Brunck
> > > <holger.brunck at hitachienergy.com> wrote:
> > >>
> > >> Hi Simon,
> > >> I got no time to try it yet but I have a general comment.
> > >>
> > >>>
> > >>> Sometimes it is useful to include a CONFIG option that contains a string.
> > >>> This is hard to do in general, since in many cases it is useful to
> > >>> have the quotes around the string so that, for example:
> > >>>
> > >>
> > >> wouldn't it be cleaner to always convert a Kconfig option which is
> > >> defined as a string to a string without the double quotes? If
> > >> someone needs them he could explicitly add them with
> > >>
> > >> bootcmd=run "CONFIG_BOARD_CMD"
> > >>
> > >> Because  in my case I have some options I use them to build
> > >> together the kernel command line I pass to the kernel.  Ok I could
> > >> store them before in an own variable and them use them with
> > >> ${variable} in the command line. But I think it would be cleaner to
> > >> always convert a string defined in Kconfig in a string without the quotes.
> What do you think?
> > >
> > > Yes I would prefer that to. I'm not sure how to implement it though.
> > > Any thoughts?
> >
> > I agree that special-casing the RHS containing a single qouted string
> > is a bad idea, it's really hard to understand and explain what the rules are.
> >
> > Unfortunately, I don't think we can just create a separate version of
> > the config.h header where the quotes are removed and then as Holger
> > suggests rely on including the double quotes when needed, because then
> > the C preprocessor would see "CONFIG_BOARD_CMD" as a string literal,
> > inside which macro expansion is not done.
> >
> > What we really want is to separate the two uses of the config values:
> > "control" and "data". One use is on conditional lines
> >
> > #if IS_ENABLED(CONFIG_FOO)
> >
> > and another is the case of substituting values into RHS values.
> >
> > It is really convenient to use the C preprocessor for the former. But
> > for the latter, it's kind of overkill, and we could probably just as
> > well implement a simple perl script (or python or whatnot) that would
> > do what we want, including stripping of double quotes from string
> > items before substitution. But adding that as a pre-pre-processor step
> > (only doing substitution on lines not beginning with a #) would break
> > down if anybody uses #include directives, and it's also an annoying
> > extra step and extra script to maintain.
> >
> > tl;dr: no, I don't have any good ideas.
> 
> This frankly also gets back to an ongoing discussion I'm having with Pali which is
> that having a Kconfig option to set a string used in the environment is well, not a
> great way to use the tool.
> 
> What I kind of want, or at least keep leaning towards, is that nothing that sets
> the environment directly should be in Kconfig, and things should be pulled from
> the text based .env files.
> 
> I don't have a complete idea / solution right now, but I'm not sure entering more
> strings in Kconfig, that end up in the environment is moving in the right direction.
> 

Ok. I was not aware that a Kconfig string should not be used in the environment
header. If this is the case I agree that we maybe then should not support it.

But currently there are several usecases for it e.g.:
cmd/Kconfig:config MTDPARTS_DEFAULT
this is a string ends up in
include/env_default.h:  "mtdparts="     CONFIG_MTDPARTS_DEFAULT         "\0"

So all these get obsolete in the future and should be defined in a board_env.txt
file?

If this is the case I will go into this direction and remove the strings I have for my
boards coming from Kconfig and move them into a board_env.txt

Best regards
Holger