On Mon, Aug 22, 2016 at 11:12:55AM +0200, Guillermo Rodriguez Garcia wrote: > >> > However, I would be glad to get rid of defaultenv-1 rather sooner than > >> > later. > >> > >> Uhm. I actually like defaultenv-1 better than defaultenv-2. Why not > >> keep both? Everyone can then make their choice :) > > > > That's interesting. What do you like better about defaultenv-1? This > > information could help me to improve defaultenv-2. > > I guess it is just a matter of personal preference but I find > defaultenv-1 easier to understand and easier to manage. With > defaultenv-1 we basically have just one configuration file to edit > (/env/config) and optionally init_board and/or boot_board (which are > not needed in a majority of the cases). So everything you need to > know/edit/tweak is in /env/config. > > With defaultenv-2 the "board configuration" is scattered through a > number of tiny files, some of which contain just a single value (see > for example nv/autoboot_timeout or nv/user). I find this more > difficult to manage -- you need to edit a lot of tiny files instead of > just one. Also I feel that the flow of control is less obvious for the > same reason. > > I'd say defaultenv-1 feels more "imperative" and defaultenv-2 feels > more "declarative", and I prefer the former. But I am fully aware that > this is just a matter of personal preference :) I understand your concerns but do not share them all. Maybe we can find a way to either make defaultenv-2 more acceptable for you or to make defaultenv-1 more appealing to me? About the number of small files that only contain a single value: defaultenv-1 was the opposite and that was a problem. Whenever a board wanted to adjust a single value, say the autoboot timeout, it had to duplicate a big file and very soon we had many nearly identical copies of that file and nobody knew what the actual change was. With NV variables this has become better. I never felt the need though to dig through the individual /env/nv files, here the 'nv' and 'global' commands or the 'magicvar' command to much better jobs. Normally you only have to hand edit /env/nv files when you want to change the default of a variable for a given board. Another thing that made another approach than with defaultenv-1 necessary was the variables that contain "net", "disk", "nor", "nand". This did not scale and was not extensible because you could not pass some arbitrary file and use it as kernel. I wonder if defaultenv-1 is not customizable enough and on the other hand your board does only boot from very special locations, do you need a generic default environment at all or are you better off using your own special environment? Finally, could this be a documentation issue? Could you have another look at defaultenv-2 and see what is not clear or what needs further convenience to be better usable? Sascha -- 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
