On Tue, Jun 17, 2025 at 12:38:21AM +0900, Masahiro Yamada wrote:
On Wed, Jun 11, 2025 at 4:38 PM Thomas Weißschuh thomas.weissschuh@linutronix.de wrote:
Various subsystems embed non-code build artifacts into the kernel, for example the initramfs, /proc/config.gz, vDSO image, etc. Currently each user has their own implementation for that.
Add a common "blob" framework to provide this functionality. It provides standard kbuild and C APIs to embed and later access non-code build artifacts into the kernel image or modules.
Reviewed-by: Nicolas Schier n.schier@avm.de Signed-off-by: Thomas Weißschuh thomas.weissschuh@linutronix.de
Kbuild provides only a small set of syntaxes, yet it's flexible enough to allow each Makefile to implement what it needs. I aim to keep Kbuild scripts as simple as possible and avoid over-engineering.
Instead, you can implement this in lib/kunit/Makefile.kunit-uapi or somewhere. That way, I do not have to be worried about what you do.
The goal was to have a framework that can be used independently of KUnit, for the usecases listed in the commit message (and a few unlisted ones). But I can go with a more specific solution, too.
Also, your separate blob approach looks questionable to me.
In your approach, the blob (kunit-example-uapi.blob.o) and the entry point (kunit-example-test.o) can be separate modules.
Indeed, however I don't see the issue for this specific point.
The entry point would be a small amount of boilerplate. I would keep the user-program blob and its entry point in the same C file.
A Makefile dependency between the C file and blob payload is also necessary.
(and I may consider writing a macro for populating a blob + knit entry)
That is what I had in during my early development, and I guess I'll go with it again.
Thomas