Re: [Buildroot] [RFC PATCH 1/2] support/scripts/genimage.sh: support creating a bmap image

["Gero Schwäricke via buildroot" <buildroot@buildroot.org>]

Hi all,

On Tue, May 21, 2024 at 10:36:39PM +0200, Yann E. MORIN wrote:
> Thomas, Dario, All,
> 
> On 2024-05-20 11:23 +0200, Thomas Petazzoni via buildroot spake thusly:
> [--SNIP--]
> > Yes, the first patch is reasonable, but if we can't apply something
> > like the second patch, then it might mean that the approach taken in
> > the first patch isn't correct. Indeed, if we can't enable by default
> > the generation of bmap-capable images in defconfigs, it kind of limits
> > the usefulness of this bmap-tool integration.

I disagree, I think not having an option for speeding up image flashing
enabled by default in defconfigs is fair. Defconfigs are intentionally
minimal, and for the sole purpose of getting people started with a
working config.

> > 
> > I was hoping for the other BR maintainers to chime in with some opinion.
> 
> Given the issues on existing setups, I am of the opinion that we should
> not enable the creation of bmap images by default, in any of our
> defconfig.
> 
> Now, do we want to include that support in our somewhat-generic genimage
> helper script? Technically, I don't have a strong opinion against,
> except it would not be exercised very often. We could have our CI jobs
> turn it on explicitly, though, so that's not too much of an issue.
> 
> However, users will not have an easy way to turn it on, except by adding
> somewhat-arcane command line options in the post-image script args.

True, it's not a beautiful solution, but a flexible one. We could also
convert the often used genimage post install step into a kconfig-urable
build step, but I don't think that's much better.

> 
> Also, it is relatively easy to add a site-local post-image script, which
> can be added to the list after the bundled one, and which will call
> bmap-tool, e.g. something like (kinda pseudo shell in places):
> 
>     #!/usr/bin/env bash
> 
>     getopts for -c configfile -z -j -J blablalba
> 
>     # Only the last image is interesting, as it presumably contains all
>     # the others
>     last_image="$(
>         sed -r -e '/^image ([^[:space:]]+).*/!d; s//\1/' "${cfg_file}" \
>         |tail -n 1
>     )"
>     image_path="${BINARIES_DIR}/${last_image}"
> 
>     bmaptool create "${image_path}" -o "${image_path}.bmap"
> 
>     if -z; then
>         gzip "${image_path}"
>     elif -j; then
>         bzip2 "${image_path}"
>     elif -J; then
>         xz "${image_path}"
>     fi

Not sure I understand correctly, but you are suggesting that each user
that wants to use bmap-tools should write their own post install script
and call genimage.sh in it? I think it won't be long until this very
generic wrapper script is requested to be added to support/scripts/. For
me including this in genimage.sh is preferable.

> 
> Ah one point: I think our generic geninage helper should ignore unknown
> options, rather than error out. This would I believe help with users
> adding site-local scripts like the above (notice the -z -j -J options
> for example).
> 
> Still, my opinion is that our defconfigs, and the associated scripts,
> are a starting point for booting known boards and somehow show-casing
> Buildroot, and set the user on tracks for them to further customise the
> configuration and the scripts to match their needs.
> 
> In this case, I don't think bmap-tools provides any special interest for
> that goal, given the integration in Buildroot is really easy, and very
> use-case specific (i.e. I know projects for which bmap-tools would be a
> drawback, given the generated images have zero hole).
> 
> > Do we have a way to detect that the bmap-tool generation will fail, and
> > in this case gracefully skip the bmap-tool logic?
> 
> I kind of disagree there. Given we won't enable the creation of bmap
> images by default, then it means the user will have to explicitly
> request the creation of a bmap image and thus, if we can't generate it,
> then we must fail explicitly.
> 

I think there are three options:

1. don't implement this and let each user figure bmap out on their own
2. implement it opt-in and generate an error if it fails
3. implement it opt-out and generate a warning if it fails

Personally I would prefer the second option: This would mean accepting
the original patch 1/2, but not 2/2. Instead of 2/2, it might be a good
idea to describe this in the manual so this option is easier to
discover. Currently only the genimage.cfg format is briefly described,
but not how this file is usually used in buildroot with genimage.sh. I'd
volunteer to update the documentation if this is accepted.

Best,
Gero

> Regards,
> Yann E. MORIN.
> 
> -- 
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'

-- 



---


grandcentrix GmbH | A Vodafone Company · Holzmarkt 1 · 50676 
*Cologne* | Phoenixseestrasse 18 · 44263 *Dortmund* · Germany
| in 
<https://www.linkedin.com/company/grandcentrix> | phone: +49-221-677-860-0 
| email: hello@grandcentrix.net <mailto:hello@grandcentrix.net>


grandcentrix cares about privacy 
<https://grandcentrix.net/de/pages/privacymail/>

Amtsgericht Köln | HRB  
70119 | Geschäftsführer: M. Krömer,  R. Hänel | USt.-IdNr.: DE266333969

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot