From mboxrd@z Thu Jan 1 00:00:00 1970 From: Maxime Ripard Date: Wed, 11 Jul 2018 15:50:10 +0200 Subject: [U-Boot] [RFC PATCH] u-boot: remove driver lookup loop from env_save() In-Reply-To: <1531305863.2477.57.camel@azcomtech.com> References: <1531227476-21591-1-git-send-email-nicholas.faustini@azcomtech.com> <01c13875-84e4-3923-9ca7-15932703df91@de.pepperl-fuchs.com> <1531298008.2477.30.camel@azcomtech.com> <20180711094838.zyczks6iksp772ir@flea> <6eff97c2-909e-c9f6-c651-dc9dc7dfe04e@de.pepperl-fuchs.com> <1531305863.2477.57.camel@azcomtech.com> Message-ID: <20180711135010.agzz3hwojjfn3gs5@flea> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de On Wed, Jul 11, 2018 at 12:44:23PM +0200, Nicholas wrote: > > > > Maybe a solution could be to have an env_save() function which > > > > acts in a similar way as proposed in my patch and an > > > > env_save_prio() function, which acts like the env_load() > > > > i.e. looking for the best working location instead of relying > > > > on what has been stored into gd-> env_load_location. > > > > > > I don't really see a use-case for overriding wherever the > > > environment at the user-level actually. At the board level, for > > > redundancy or transition, yes, definitely, but we can already do > > > that. > > > > Well, the use case I saw was that I wanted to test redundant > > environment  storage. I admit this is not an end user use case but > > a developer use  case, so I guess you're right. > > > > So after fixing this endless loops I see two questions: - to which > > environment do we store if the one in 'env_load_location'  fails > > to store? > > Good question. My opinion is that it strongly depends on what we want > to achieve with the implementation: do we want 1) to keep the > consistency between load and save, or we want 2) to guarantee to be > able to load/save from at least one location?  > > If 1) then a failure on env_save() simply fails and doesn't store > anything. In other words we are multi-env when loading but single-env > when storing. We are actually binding env_save() to the last > env_load()'s result. > > If 2) then a failure on env_save() will try all the available locations > but we are open to misalignments. Here we are full multi-env since > env_save() and env_load() are not bound together. In that case, we don't want to store to a lower priority, but to a higher one. Otherwise, the environment will be saved just fine, but will not be read next time, which will be very confusing to the user. And with a higher priority, you might end up overwriting something you weren't expecting to overwrite, so I'd vote 1. -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: