On Wed, Jul 13, 2022 at 01:11:35AM +0200, Pali Rohár wrote: > On Tuesday 12 July 2022 18:58:31 Tom Rini wrote: [snip] > > It really isn't, that's why the plain text environment stuff is a good > > step in the right direction. What I'm not sure about how to best handle > > is making it easy for a user, rather than developer, to override > > environment values too. What I mean he > > Maybe the important question is: Why is needed CONFIG_PREBOOT define at > all? Why it is not enough just to set preboot= env variable? And same > questions for all other CONFIG_<name_of_env> options.
I'm sorry if this sounds snarky, I don't intend it to. But, size. Maybe that doesn't matter so much these days for the size savings on run_preboot_environment_command(). > > > For all this stuff is needed some stronger tool/language than Kconfig, > > > e.g. C preprocessor (like it was before in config.h) or any similar > > > stronger macro language (e.g. m4) or script languages (shell / python). > > > > Yes, so, take a look at 5c3f6a320678d64c9fa0c42755488822a033b567 as an > > example of moving a board away from board config.h and to something > > else. What I'm not sure on is how to best handle preboot in this case > > as I'm not quite liking "Enable CONFIG_PREBOOT and then edit > > .../boardname.env to set preboot to the right value". > > > > -- > > Tom > > With that commit, all env variables are moved into separate file. This > file can be parsed by other tools and at compile it is possible to > extract current value of preboot= env variable or check if preboot= is > defined. Cannot be by this logic automatically defined/expanded > CONFIG_PREBOOT symbol? Of course, it would not be Kconfig symbol > anymore. That sounds interesting. -- Tom
signature.asc
Description: PGP signature