Re: [PATCH v3 07/16] kbuild: introduce blob framework

[Thomas Weißschuh]

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@xxxxxxxxxxxxx> 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@xxxxxx>
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@xxxxxxxxxxxxx>
> 
> 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