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

["Yann E. MORIN" <yann.morin.1998@free.fr>]

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

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

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.

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.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot