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
