[PATCH 11/11] bootm: Support string substitution in bootargs

[Wolfgang Denk <wd@denx.de>]

Dear Simon,

In message <CAPnjgZ2Vn3oWAHy71smw-+fRo28HUA0K32DP6FPoGtjtK3XoFQ@mail.gmail.com> you wrote:
>
> Well my series does that to a large extent. It is much more like bootm
> now, in that it is properly split into stages. I think it would be
> possible to combine parts of it into bootm as a future step, although
> it is non-trivial, and I think we should build out more tests first.

Hm... I fear that this is rather cementing the zboot support so we
never get rid of it...
>
> But zboot does make use of an existing command line and does all the
> weird x86 processing, so I don't know how we could get rid of it.

How about a command that takes this existing command line and
"imports" it into a standard bootargs variable?

> I don't think the actual mechanism is a big deal. We could do a string
> replace (does U-Boot support that?) of %U with ${uuid} for example, to
> make it work for my case.

Yes, we can.

=> env print commandline bootargs
## Error: "commandline" not defined
## Error: "bootargs" not defined
=> env set commandline 'This is a %A test for %U replacement.'
=> setexpr bootargs gsub %A boring "${commandline}"
bootargs=This is a boring test for %U replacement.
=> setexpr bootargs gsub %U '${uuid}'
bootargs=This is a boring test for ${uuid} replacement.
=> env print bootargs
bootargs=This is a boring test for ${uuid} replacement.

> Or we could go with an idea I previously rejected, to just provide a
> simple string replace feature, with any special characters in the
> search string. For example:

But we have all this already, even with regular expressions and
(simple) backreferences.


> > Sorry, I don't understand what you mean heare.  What is "the same
> > env var" versus "anything else"?  Maybe you can give a specific example?
>
> Did you see the 'run regen_scripts' script?
>
> At present I can do
>
> setenv uuid blah; setenv partid blah; bootm
>
> but with your scheme I need the 'run regen_script' to set the
> variables correctly, which is a real pain as my example shows.

Just insert a "run" there, and you are done with it.

> My point here is not about %U, it is about the pain of multiple stages
> to get the variables right. WIth bootargs substitution we can just set
> the variables and boot.

I think this is not so much a bootargs question (or at least it
should not be it).  bootargs is just another environment variable
without any specific properties except that it's content is being
passed to the kerenl, so you want to have the needed variable
substituion doen before that.

It was an intentional decison not to do this automagically, based on
the thinking that accorsing to UNNIX philosophy it is not each
individual command which implements things like wildcard or variable
substitution, but rather this is something the shell does for you,
and the commands are dumb in this respect.  This works reasonably
well, except that we don't pass bootargs as argument to the bootm
command - rather it is done internally by default, this lacking the
variable substituion.

You may call this a design bug, and I will accept the blame for it.

To me the obvious fix would be to correct this behavious such that
we extend bootm to accept the bootargs argument as a command line
parameter, thus enabling variable substitution there, too.

As far as I'm concenred, I don't think this is necessary as all it
takes to work around this is a single call of a "run" command which
can do exactly that, too.

But I agree, this is just a workaround, and it would be more
consistent to pass bootargs as argument directly.


And this is also the direction I see how the zboot stuff should be
fixed:  import the Linux command line into the environment, modify
it as needed (if necessary using regular expression matching /
string substituion to fix it up to use common U-Boot variable
names), and then pass it like the rest of the world to the kernel.

> Can we step past the %U business? I think we can use the ${var} stuff
> with some substitution.

Don't we have that already?  What exactly is it you miss?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Steal five dollars and you were a petty  thief.  Steal  thousands  of
dollars and you are either a government or a hero.
                                   - Terry Pratchett, _Going_Postal_