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

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

[Guillermo Rodriguez Garcia]

Hello all,

Currently, for defaultenv v1, the /env/bin/boot_board script is called
from /env/bin/init.

However this means boot_board will not be run if booting manually (by
running 'boot' from the barebox console).

Shouldn't this script be called from /env/bin/boot instead? If a board
needs any specific stuff to be done when booting, this probably
applies both when autobooting and when booting manually (otherwise,
anything that only applies only when autobooting could also be done
from init_board instead of boot_board).

Opinions?

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com

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

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

[Sascha Hauer]

Hi,

On Tue, Aug 16, 2016 at 10:42:32AM +0200, Guillermo Rodriguez Garcia wrote:
> Hello all,
> 
> Currently, for defaultenv v1, the /env/bin/boot_board script is called
> from /env/bin/init.
> 
> However this means boot_board will not be run if booting manually (by
> running 'boot' from the barebox console).
> 
> Shouldn't this script be called from /env/bin/boot instead? If a board
> needs any specific stuff to be done when booting, this probably
> applies both when autobooting and when booting manually (otherwise,
> anything that only applies only when autobooting could also be done
> from init_board instead of boot_board).

The only boot_board script we have is
arch/arm/boards/at91sam9m10g45ek/env/bin/boot_board. Here a menu is
built which I think makes sense at that stage and not at init_board.

However, I would be glad to get rid of defaultenv-1 rather sooner than
later.

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

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

[Guillermo Rodriguez Garcia]

Hello,

2016-08-18 8:31 GMT+02:00 Sascha Hauer <s.hauer@pengutronix.de>:
> Hi,
>
> On Tue, Aug 16, 2016 at 10:42:32AM +0200, Guillermo Rodriguez Garcia wrote:
>> Hello all,
>>
>> Currently, for defaultenv v1, the /env/bin/boot_board script is called
>> from /env/bin/init.
>>
>> However this means boot_board will not be run if booting manually (by
>> running 'boot' from the barebox console).
>>
>> Shouldn't this script be called from /env/bin/boot instead? If a board
>> needs any specific stuff to be done when booting, this probably
>> applies both when autobooting and when booting manually (otherwise,
>> anything that only applies only when autobooting could also be done
>> from init_board instead of boot_board).
>
> The only boot_board script we have is
> arch/arm/boards/at91sam9m10g45ek/env/bin/boot_board. Here a menu is
> built which I think makes sense at that stage and not at init_board.

The thing is, if boot_board is called from init, then it will not be
called if autoboot is interrupted and you later boot manually with the
boot command.

We actually use boot_board to do some board-specific processing that
should be done both when autobooting and when booting "manually". The
way it is right now, this is not possible.

With the change I am proposing, boards such as at91sam9m10g45ek could
still do what they are doing now (just move the code to init_board
instead). Or, with some tweaking, perhaps it could even be left in
boot_board (with boot_board being called from boot).

Is this specific board the only objection to the change I am
proposing? If so I could try to come up with a patch which accomodates
this specific case. Or are there other, more general objections?

>
> 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 :)

Regards,

Guillermo Rodriguez Garcia
guille.rodriguez@gmail.com

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

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

[Sascha Hauer]

On Thu, Aug 18, 2016 at 10:02:48AM +0200, Guillermo Rodriguez Garcia wrote:
> Hello,
> 
> 2016-08-18 8:31 GMT+02:00 Sascha Hauer <s.hauer@pengutronix.de>:
> > Hi,
> >
> > On Tue, Aug 16, 2016 at 10:42:32AM +0200, Guillermo Rodriguez Garcia wrote:
> >> Hello all,
> >>
> >> Currently, for defaultenv v1, the /env/bin/boot_board script is called
> >> from /env/bin/init.
> >>
> >> However this means boot_board will not be run if booting manually (by
> >> running 'boot' from the barebox console).
> >>
> >> Shouldn't this script be called from /env/bin/boot instead? If a board
> >> needs any specific stuff to be done when booting, this probably
> >> applies both when autobooting and when booting manually (otherwise,
> >> anything that only applies only when autobooting could also be done
> >> from init_board instead of boot_board).
> >
> > The only boot_board script we have is
> > arch/arm/boards/at91sam9m10g45ek/env/bin/boot_board. Here a menu is
> > built which I think makes sense at that stage and not at init_board.
> 
> The thing is, if boot_board is called from init, then it will not be
> called if autoboot is interrupted and you later boot manually with the
> boot command.

I think you are right, just go ahead with the suggested change. With
that a menu will be shown on the at91sam9m10g45ek when doing a manual
'boot' which may even be the desired behaviour.

> 
> >
> > 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.

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

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

[Guillermo Rodriguez Garcia]

Hi Sascha,

2016-08-22 7:45 GMT+02:00 Sascha Hauer <s.hauer@pengutronix.de>:
> On Thu, Aug 18, 2016 at 10:02:48AM +0200, Guillermo Rodriguez Garcia wrote:
>> Hello,
>>
>> 2016-08-18 8:31 GMT+02:00 Sascha Hauer <s.hauer@pengutronix.de>:
>> > Hi,
>> >
>> > On Tue, Aug 16, 2016 at 10:42:32AM +0200, Guillermo Rodriguez Garcia wrote:
>> >> Hello all,
>> >>
>> >> Currently, for defaultenv v1, the /env/bin/boot_board script is called
>> >> from /env/bin/init.
>> >>
>> >> However this means boot_board will not be run if booting manually (by
>> >> running 'boot' from the barebox console).
>> >>
>> >> Shouldn't this script be called from /env/bin/boot instead? If a board
>> >> needs any specific stuff to be done when booting, this probably
>> >> applies both when autobooting and when booting manually (otherwise,
>> >> anything that only applies only when autobooting could also be done
>> >> from init_board instead of boot_board).
>> >
>> > The only boot_board script we have is
>> > arch/arm/boards/at91sam9m10g45ek/env/bin/boot_board. Here a menu is
>> > built which I think makes sense at that stage and not at init_board.
>>
>> The thing is, if boot_board is called from init, then it will not be
>> called if autoboot is interrupted and you later boot manually with the
>> boot command.
>
> I think you are right, just go ahead with the suggested change. With
> that a menu will be shown on the at91sam9m10g45ek when doing a manual
> 'boot' which may even be the desired behaviour.

Perfect. Will do so.

>> > 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 :)

Guillermo

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

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

[Holger Schurig]

Guillermo Rodriguez Garcia <guille.rodriguez@gmail.com> writes:

> 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.

Hi,

on my device I use defaultenv-1 for the same reason. Basically I just
have one env/bin/init and one env/config file and that's it. And the
env/config one is even so small that I could fold it into env/bin/init.

This even more so as my device is "set in stone", e.g. there is no SPI
EEPROM or other means (partition) to store an environment. What comes
with the compiled barebox is the environment.

Having things in one place and not scattered around makes things visible
at a glance.

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

[PATCH] Call boot_board from boot, not from init.

[Guillermo Rodriguez]

From: grodriguez <guille.rodriguez@gmail.com>

This ensures that any board-specific code that must be run at
boot time will be run both when autobooting and when manually
running the 'boot' command from the console.

Signed-off-by: Guillermo Rodriguez <guille.rodriguez@gmail.com>
---
 defaultenv/defaultenv-1/bin/boot |    4 ++++
 defaultenv/defaultenv-1/bin/init |    5 ++---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/defaultenv/defaultenv-1/bin/boot b/defaultenv/defaultenv-1/bin/boot
index c17ccdb..a5d6596 100644
--- a/defaultenv/defaultenv-1/bin/boot
+++ b/defaultenv/defaultenv-1/bin/boot
@@ -2,6 +2,10 @@
 
 . /env/config
 
+if [ -f /env/bin/boot_board ]; then
+	. /env/bin/boot_board
+fi
+
 if [ x$kernel_loc = xnet ]; then
 	kernel_loc=tftp
 fi
diff --git a/defaultenv/defaultenv-1/bin/init b/defaultenv/defaultenv-1/bin/init
index a55d293..2dcddbe 100644
--- a/defaultenv/defaultenv-1/bin/init
+++ b/defaultenv/defaultenv-1/bin/init
@@ -23,9 +23,8 @@ if [ -f /env/bin/init_board ]; then
 fi
 
 echo -e "\e[?25h"
-if [ -f /env/bin/boot_board ]; then
-	. /env/bin/boot_board
-elif [ -n $autoboot_timeout ]; then
+
+if [ -n $autoboot_timeout ]; then
 	echo -n "Hit any key to stop autoboot: "
 	timeout -a $autoboot_timeout
 	if [ $? != 0 ]; then
-- 
1.7.9.5


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

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

[Sascha Hauer]

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

Re: [PATCH] Call boot_board from boot, not from init.

[Sascha Hauer]

On Mon, Aug 22, 2016 at 03:45:34PM +0200, Guillermo Rodriguez wrote:
> From: grodriguez <guille.rodriguez@gmail.com>
> 
> This ensures that any board-specific code that must be run at
> boot time will be run both when autobooting and when manually
> running the 'boot' command from the console.
> 
> Signed-off-by: Guillermo Rodriguez <guille.rodriguez@gmail.com>
> ---
>  defaultenv/defaultenv-1/bin/boot |    4 ++++
>  defaultenv/defaultenv-1/bin/init |    5 ++---
>  2 files changed, 6 insertions(+), 3 deletions(-)

Applied, thanks

Sascha

> 
> diff --git a/defaultenv/defaultenv-1/bin/boot b/defaultenv/defaultenv-1/bin/boot
> index c17ccdb..a5d6596 100644
> --- a/defaultenv/defaultenv-1/bin/boot
> +++ b/defaultenv/defaultenv-1/bin/boot
> @@ -2,6 +2,10 @@
>  
>  . /env/config
>  
> +if [ -f /env/bin/boot_board ]; then
> +	. /env/bin/boot_board
> +fi
> +
>  if [ x$kernel_loc = xnet ]; then
>  	kernel_loc=tftp
>  fi
> diff --git a/defaultenv/defaultenv-1/bin/init b/defaultenv/defaultenv-1/bin/init
> index a55d293..2dcddbe 100644
> --- a/defaultenv/defaultenv-1/bin/init
> +++ b/defaultenv/defaultenv-1/bin/init
> @@ -23,9 +23,8 @@ if [ -f /env/bin/init_board ]; then
>  fi
>  
>  echo -e "\e[?25h"
> -if [ -f /env/bin/boot_board ]; then
> -	. /env/bin/boot_board
> -elif [ -n $autoboot_timeout ]; then
> +
> +if [ -n $autoboot_timeout ]; then
>  	echo -n "Hit any key to stop autoboot: "
>  	timeout -a $autoboot_timeout
>  	if [ $? != 0 ]; then
> -- 
> 1.7.9.5
> 
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 

-- 
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

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

[Guillermo Rodriguez Garcia]

Hi Sascha,

2016-08-23 10:13 GMT+02:00 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.

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@gmail.com

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

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

[Sascha Hauer]

On Wed, Aug 24, 2016 at 04:42:42PM +0200, Guillermo Rodriguez Garcia wrote:
> Hi Sascha,
> 
> 2016-08-23 10:13 GMT+02:00 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.
> 
> 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?

It's my interest to keep the diversion between boards small. Normally
as a barebox user you shouldn't care about the particular type of the
board you have, instead it should always feel the same (Or, if you
decide to customize barebox via Kconfig or patches, it should be
applyable for all boards without having to repeat this step for every
board you use in the future). defaultenv-1 make this goal hard to
archieve. Most boards only copy and modify /env/config, but some also
duplicate /env/boot and other files. /env/boot is problematic because
it contains behaviour, not configuration. With each duplication we
introduce a new behaviour which means that this board beahves different
from the rest of the boards and also won't get updates from the generic
/env/boot file anymore.
This all is not problematic when you only care about one board or a few
boards that you use, but is a nightmare when you have > 100 boards
from which you only have access to a few of them. defaultenv-2 is better
in this regard since we can do adjustments without changing other things
and it generally needs less adjustments.

I think it's not really defaultenv-1 that disturbs me, but more the
in-tree users of it. Also it's not really nice that by choosing a board
you also choose between defaultenv-1 and defaultenv-2. It would be much
nicer if these choices were independent.

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