On Tuesday 12 July 2022 19:15:45 Tom Rini wrote: > 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().
Size is really a good argument. > > > > 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 And this solve also issue with size (if we can determinate at compile time if preboot= env is defined or not).
