On Mon, Jan 20, 2020 at 05:30:57PM +0000, Joel Johnson wrote: > > > On January 20, 2020 5:15:37 PM UTC, Tom Rini <tr...@konsulko.com> wrote: > >On Mon, Jan 20, 2020 at 10:09:21AM -0700, Joel Johnson wrote: > >> On 2020-01-20 09:51, Wolfgang Denk wrote: > >> > Dear Joel, > >> > > >> > In message <20200119073738.29189-1-mrj...@lixil.net> you wrote: > >> > > This enables the building user to specify environment values to > >be > >> > > included in the static default_environment with an image. This is > >> > > useful to build multiple otherwise like configured images, > >varying > >> > > by environment unique entries. > >> > > > >> > > --- > >> > > > >> > > I expected something like this to already be present, but > >couldn't > >> > > find such a mechanism. I also assumed that something similar may > >> > > have been proposed previously, but also couldn't find anything > >via > >> > > searching. > >> > ... > >> > > >> > > +config USER_ENV_SETTINGS > >> > > + string "User build-time additional environment entries" > >> > > + help > >> > > + This value is reserved for the building user to provide > >custom > >> > > + environment entries to be added to the default environment. > >Care > >> > > must > >> > > + be taken to not break the environment, incompatible entries > >may > >> > > cause > >> > > + failure to compile, or failure of the target board to > >properly > >> > > + initialize or boot. The format is key=value pairs, with > >entries > >> > > + separated by C-style escaped null terminated values, such as: > >> > > + "key1=valueA\0key2=valueB\0key3=valueC". > >> > > >> > Something in your descripotion must be missing, or this change > >makes > >> > no sense to me. > >> > > >> > > #ifdef CONFIG_EXTRA_ENV_SETTINGS > >> > > CONFIG_EXTRA_ENV_SETTINGS > >> > > +#endif > >> > > +#ifdef CONFIG_USER_ENV_SETTINGS > >> > > + CONFIG_USER_ENV_SETTINGS > >> > > #endif > >> > > >> > What exactly is the difference between CONFIG_EXTRA_ENV_SETTINGS > >and > >> > CONFIG_USER_ENV_SETTINGS for you, i. e. what can you do with > >> > CONFIG_USER_ENV_SETTINGS that cannot be done in exatly the same way > >> > with CONFIG_EXTRA_ENV_SETTINGS? > >> > > >> > Maybe it would help if you include any code that is actually using > >> > this feature? > >> > > >> > Best regards, > >> > > >> > Wolfgang Denk > >> > >> The main different to me is that many boards set/replace > >> CONFIG_EXTRA_ENV_SETTINGS, making it unusable as a user build-time > >> configuration value. As a result, I can actually specify values for > >> CONFIG_USER_ENV_SETTINGS and have them included in the resulting > >environment > >> instead of overridden by the board configuration. > >> > >> There is intentionally no code using this feature, as meant in the > >> description it is intended to be reserved for the building user's > >usage. The > >> specific use case for which I'm using it is to ease building of > >multiple > >> otherwise identical images, embedding a fixed and well known set of > >ethernet > >> MAC addresses into each unique image for execution in environments > >with no > >> environment storage. It is meant to be used for any other values > >changed or > >> added in the default image environment though - if there is a better > >way to > >> accomplish this I'd be all for it, but I couldn't find anything, thus > >the > >> RFC patch. > > > >I think part of the problem is that CONFIG_EXTRA_ENV_SETTINGS needs to > >be migrated to Kconfig. And that in turn shows that some amount of > >things need to be taken out of the CONFIG namespace and moved in to > >distinct headers to be included / keyed-in-to. What we have in > >include/environment/ti/ is a start to that but far from complete. > > That sounds like a good path indeed, but wouldn't that still result in the > Kconfig value being required to contain the full extra contents? The nice > thing about a separate config entry is that it can serve as an overlay of > just selected overrides and/or custom entries, instead of requiring following > and updating user configs for in-source changes which are unrelated, but > still captured in board level EXTRA > > Either way works, I'd still be in favor of a separate overlay, thus the RFC > patch. If you'd like it all eventually consolidated in EXTRA then I'll just > carry the patch locally.
It's really hard to say how much of what's in CONFIG_EXTRA_ENV_SETTINGS today should stay that way vs being put in to a common header that can be re-used. That in fact might lead to making it easier to include an additional file of environment contents as while we can put in escape-sequenced strings via Kconfig (and do for mtdparts related stuff) it's really not user-friendly and another case of where we're encoding information via Kconfig that could be done more nicely. -- Tom
signature.asc
Description: PGP signature
