Dear Rasmus, In message <76615995-6700-1b3e-b598-4913e9882...@prevas.dk> you wrote: > > >> The default environment is something which is NOT INTENDED for > >> regular use. it is what you will fall back to in case (and ONLY in > >> that case) when your regular persistent environment cannot be used, > >> for example because it is not readable (I/O errors or such) or not > >> properly initialized or corrupted (CRC checksum error). > > You seem to be ignoring the many cases where one chooses, for > simplicity, robustness and/or security, not to have a writable > environment at all.
You seem to ignore what I write. Yes, there are many use cases where no writable environment is needed / wanted, but this is not what the default environment was intended for. For such cases some null driver similar to /dev/null should be used. > I'm not really doing anything other than allowing a > CONFIG_ENV_EXTRA_SETTINGS to live in .dtb rather than cooking all of it > into the U-Boot binary itself. That's where board-specific additions are > supposed to live nowadays I'd assume. Your statement is incorrect. CONFIG_ENV_EXTRA_SETTINGS is something that is processed at compile time, while your code attempts to modify the default environment in run time. these are totally different things. > >> And please, for the sake of avoiding further confusiion, please do > >> not name this "default-environment". > > Sure. So would you be ok with some /config/extra-environment node which > gets appended after the normal environment has been loaded? Then if I In principle yes, I see that this is a nice and useful feature. Just the notation of "append" seems wrong to me. We already have "env import" which can import additional / new environmane settings in different formats. What I think should be done is extending this by support for a new format (you may call it driver if you want) to import environment settings from a DTB. > set CONFIG_ENV_IS_NOWHERE, I'd get what I have now. The only problem Can't you see that this is not logical? If the environment is nowhere, then how can you add something to it? > with that is that it might be a little weird to have static content of > the chosen control dtb override something that might have been loaded > from a writable storage location. But that's not really an intended > combination anyway, and I can probably add a knob that allows one to > choose whether the .dtb settings should be applied or not. This is not weird in any way - this is what the "env import" command does by definition: it imports environment settigns from some other storage. > > I wonder if we should have a way to load the (whole) environment from DT? > > That will be my second choice, i.e. adding a "CONFIG_ENV_IS_IN_DTB" > which obviously doesn't support saving, but has the advantages I'm after > here of using one U-Boot binary with slightly different environments. I see no difference here. "env import" into an empty environment does just that. 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: w...@denx.de The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense. - E. W. Dijkstra
