Allow multi kernel image builds

[alexgg]

---

Contributor checklist

• Changes have been tested
  • Covered in automated test suite
  • Manual test case recorded
• Change-type present on at least one commit
• Signed-off-by is present
• The PR complies with the Open Embedded Commit Patch Message Guidelines

Reviewer Guidelines

• When submitting a review, please pick:
  • 'Approve' if this change would be acceptable in the codebase (even if there are minor or cosmetic tweaks that could be improved).
  • 'Request Changes' if this change would not be acceptable in our codebase (e.g. bugs, changes that will make development harder in future, security/performance issues, etc).
  • 'Comment' if you don't feel you have enough information to decide either way (e.g. if you have major questions, or you don't understand the context of the change sufficiently to fully review yourself, but want to make a comment)

[flowzone-app]

Website deployed to CF Pages, 👀 preview link https://35dc041f.balena-os.pages.dev

[ycardaillac]

Hey @alexgg,

As you said this is only a part of the overall kernel and kernel module hostapp extension.

I see that there's a telling comment in meta-balena-raspberrypi that explain why we do this.

At first I thought that this was a re-edit of the config fragment mechanism of poky, so perhaps we should precise that poky's mechanism uses on SRC_URI and yours uses in FILESEXTRAPATHS. We could also explain why we do that. I suppose that it is so that we can have a kernel vendor not base on kernel-yocto and still have our own fragment added?

Also I'm wondering if we should merge this mechanism on its own or if we should wait for the rest of the feature? Is this whole change useful on its own?

[alexgg]

@ycardaillac

I see that there's a telling comment in meta-balena-raspberrypi that explain why we do this.

It's also explained in the commit log.

At first I thought that this was a re-edit of the config fragment mechanism of poky, so perhaps we should precise that poky's mechanism uses on SRC_URI and yours uses in FILESEXTRAPATHS.

It is explained in the commit log.

We could also explain why we do that. I suppose that it is so that we can have a kernel vendor not base on kernel-yocto and still have our own fragment added?

The reasoning for the change is also in the commit log:

• It lets recipes ship fragments by dropping them in ${THISDIR}/files/ (or any
  FILESEXTRAPATHS-reachable dir) without touching SRC_URI.
• Allows sharing of kernel fragments across kernel siblings
• Allow fragments to override BALENA_CONFIGS-injected values when needed.

Basically, it adds a mechanism that extensions can use to customize a kernel. Neither Yocto's default or the balenaOS kernel class allow this.

And indeed it's generic so it works independently of the kernel-yocto class.

Also I'm wondering if we should merge this mechanism on its own or if we should wait for the rest of the feature? Is this whole change useful on its own?

It's an independent mechanism to add kernel configuration so it stands on its own. There is no roadmap for extensions yet so there is no rest of the feature to wait for. Without it, extensions would just work, but they will have no clean interface to overriding kernel and modules. But extensions that won't need this would just work fine.