Re: Fwd: Shouldn't boot_board be called from boot instead of init?

[Sascha Hauer <s.hauer@pengutronix.de>]

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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox