Re: envfs: provide an intentional way to ignore an existing external environment

["Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>]

Hello Michael,

On Wed, Aug 06, 2014 at 09:04:13AM +0200, Michael Olbrich wrote:
> On Thu, Jul 31, 2014 at 09:44:16AM +0200, Uwe Kleine-König wrote:
> > On Thu, Jul 31, 2014 at 09:33:02AM +0200, Juergen Borleis wrote:
> > > On Thursday 31 July 2014 09:14:25 Uwe Kleine-König wrote:
> > > > [...]
> > > > Compared with storing the default environment in the external store the
> > > > only difference is that you don't need to modify it if you change the
> > > > internal one, right?
> > > 
> > > This would also be an advantage of this new feature.
> > The only one even?
> > 
> > > > I wonder what the targeted use case is.
> > > 
> > > To use an external stored environment *only* for development purposes or tests 
> > > and to keep the possibility to do so.
> > Doesn't make a warm and cosy feeling. Isn't it easier and more robust to
> > just not tell barebox about the external storage at all and for the
> > testing/development procedure do an explicit
> > 
> > 	loadenv /dev/tralala
> 
> That doesn't help at all. There are several changes that I regularly use
> that are required when init runs, so a manual loadenv is too late:
> - global.autoboot_timeout=3 (the build-in value is 0 to boot faster by
>   default).
Ok, that might be annoying, but I'd say this doesn't justify the
Jürgen's changes.

> - nfs automounts that contain '$user'
Don't get this one. The nice thing about automount is that they are done
on request, so isn't it early enough to set global.user when loading the
debug environment (probably resulting in another line to type)?

Even though Jürgen predicted that developers won't like me for the
suggestion, I still think it's wrong to change a production system for
debug purposes.

IMHO a righter thing would be to implement an extension to microcom that
catches the 0s prompt, interrupts it and types

	loadenv /dev/tralala
	global.user=mol

for you. If I didn't miss anything that would catch all problems without
the need to change barebox.

> Also, this requires me to know _where_ the environment is. And that is not
/dev/tralala could be the same for all configurations :-) 

> easy to remember when I need to work with multiple devices a day and gets
> worse, when it changes with the boot source (SD/eMMC). Mistakes are
> guaranteed.
I'd say, either you want a) an environment that is used always, or b)
you don't.

With a) you can do your modifications to increase boot time and set the
username and save it for development. If you want to reset it to
"production mode" just do: loadenv /dev/default_env; saveenv;

With b) either live with the decision and adapt your *development*
workflow to it, or change to a).

Just my 0.02€, feel free to ignore them.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox