From: Guillermo Rodriguez Garcia <guille.rodriguez@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: Fwd: Shouldn't boot_board be called from boot instead of init?
Date: Mon, 22 Aug 2016 11:12:55 +0200 [thread overview]
Message-ID: <CABDcavb3DN9Hc-Gr-vYG6aPHBgMYhM__4BzxVAjEqp5MdhB6qA@mail.gmail.com> (raw)
In-Reply-To: <20160822054521.GU20657@pengutronix.de>
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
next prev parent reply other threads:[~2016-08-22 9:13 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CABDcavbrkt2q3cQ5Tzi3d0pU+Pm3v4S3OGzFo_aG_SNgmEgOnA@mail.gmail.com>
2016-08-16 8:42 ` Guillermo Rodriguez Garcia
2016-08-18 6:31 ` Sascha Hauer
2016-08-18 8:02 ` Guillermo Rodriguez Garcia
2016-08-22 5:45 ` Sascha Hauer
2016-08-22 9:12 ` Guillermo Rodriguez Garcia [this message]
2016-08-22 9:46 ` Holger Schurig
2016-08-23 8:13 ` Sascha Hauer
2016-08-24 14:42 ` Guillermo Rodriguez Garcia
2016-08-29 7:06 ` Sascha Hauer
2016-08-22 13:45 ` [PATCH] Call boot_board from boot, not from init Guillermo Rodriguez
2016-08-24 10:33 ` Sascha Hauer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABDcavb3DN9Hc-Gr-vYG6aPHBgMYhM__4BzxVAjEqp5MdhB6qA@mail.gmail.com \
--to=guille.rodriguez@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox