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

[Tom Rini]

On Mon, Nov 07, 2022 at 11:12:48AM +0100, Rasmus Villemoes wrote:
> On 04/11/2022 20.08, Simon Glass wrote:
> > Hi Holger,
> > 
> > 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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20221107/1cf6d260/attachment.sig>