Hi Sascha, 2016-08-23 10:13 GMT+02:00 Sascha Hauer <s.hauer@xxxxxxxxxxxxxx>: > 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. Not sure what you mean with duplicating a big file. With defaultenv-1 most of the time the only single file you need to edit is /env/config, which is quite small, and most of it should be board specific anyway. I find this (the fact that all I need to edit/tweak is in that single file) quite convenient. > 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 can understand that one. But on the other hand not every target needs that flexibility. That's why I said that I don't see the need to drop defaultenv-1. Isn't it better to leave both defaultenv-1 and defaultenv-2 alive and let everyone decide which one suits them best? My impression when I look at defaultenv-2 is as described above: OK, more flexibility (which I currently don't need), but also more complexity, configuration scattered over more files, more management overhead. Plus, I'm happy with defaultenv-1, so why change? > > 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? In my case, I am currently using barebox on 3 boards. All of them support multiple boot sources (NAND, NOR, MMC) plus NFS. For all of them I only needed to edit /env/config; the other files in the default environment (init, update, boot) all work fine. So (for me) defaultenv-1 was customizable enough, and I did indeed benefit from having a generic default environment instead of a custom one written from scratch. > > 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? I think the documentation is fine as a reference. Perhaps a tutorial showing how to migrate from defaultenv-1 to defaultenv-2 could help "convert" people to defaultenv-2 by holding their hand and taking them from what they know (defaultenv-1) to the "new stuff". But even then I still wonder -- why not let both approaches coexist? Best, Guillermo Rodriguez Garcia guille.rodriguez@xxxxxxxxx _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
