From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 6 Nov 2020 15:45:57 -0500 Subject: [PATCH] env: env_sf: don't set .init op if not needed In-Reply-To: References: <20201101133812.18701-1-michael@walle.cc> <287855.1604321503@gemini.denx.de> <305086.1604389962@gemini.denx.de> <8ff3b8ad-8c4e-fe99-69c8-7c174e997a49@prevas.dk> <391556.1604594414@gemini.denx.de> Message-ID: <20201106204557.GG5340@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Nov 06, 2020 at 08:46:27AM +0100, Rasmus Villemoes wrote: > On 05/11/2020 17.40, Wolfgang Denk wrote: > > Dear Rasmus, > > > > In message <8ff3b8ad-8c4e-fe99-69c8-7c174e997a49@prevas.dk> you wrote: > >> > >>>> Not in a none standard way! Instead you can define more than one > >>>> environment storage devices and load them in a board specific order > >>>> (defined thorugh board specfif function env_get_location()) > >>> > >>> Yes, agreed. But this logically impossible if there is no storage > >>> at all, which is what CONFIG_ENV_IS_NOWHERE says. > >> > >> Then should all the current config options CONFIG_ENV_IS_ be renamed to > >> CONFIG_ENV_MAY_BE_? Because that's really what they mean. > > > > This is not correct. > > > > The CONFIG_ENV_IS_FOO means: if you use "env save", then U-Boot will > > write the config to external storage using the FOO storage device. > > Wolfgang, you're wrong. What you're saying was once true, when the > location was a "choice" in Kconfig, but it hasn't been that since > fb69464eae. Nowadays one can select multiple possible backends, and only > one of them will be used when doing "env save". > > Later (208bd2b8), _NOWHERE was made non-mutually-exclusive with the real > storage targets. Yes. It's intentional that "NOWHERE" means that if this is our run-time location for the environment, then you cannot save the environment. But since we finally implemented the ability to have more than one option enabled and pick the correct one at run time, we build both "mmc" and "nowhere". > > If you define CONFIG_ENV_IS_NOWHERE, I would for example expect that > > all "env save" related code is omitted as we will never need it. > > I haven't checked, but that functionality does seem to exist - not > depending on whether CONFIG_ENV_IS_NOWHERE is not selected, but whether > any of the CONFIG_ENV_IS_ is. See the ENV_IS_IN_DEVICE logic > in cmd/nvedit.c. So if you select CONFIG_ENV_IS_NOWHERE and not any of > the others, I think the build works as you'd expect. So, CMD_SAVEENV exists. If you don't enable that, I would expect save-related code that can be garbage collected to be discarded. It's unclear without further digging if there's code that could be discarded that is not, but checking the map file for a "nowhere" only build would probably be somewhat instructive. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: