On Wed, Aug 06, 2014 at 09:28:56AM +0200, Uwe Kleine-König wrote: > 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. Some hardware cannot be interrupted reliably with global.autoboot_timeout=0 That is more than annoying. > > - 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)? Because it's my custom automount that doesn't exist in the default usecase. > 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 and setup my automount > 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 :-) So defining a not-really-default-environment device is a better solution than these patches? > > 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). and there is c): I want to start with the default environment but change it later without confusing the user. And right now that's not possible. A clean setup means writing barebox and overwriting the environment with something. Currently thats 'nothing' with confuses to user with an error message. In the past I could use the default environment, but that no longer exists as a single environment file. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
