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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250617094327-373f046c-4010-4939-bd07-51365b665cdd@linutronix.de>
Date: Tue, 17 Jun 2025 09:50:58 +0200
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: Nathan Chancellor <nathan@...nel.org>, 
	Andrew Morton <akpm@...ux-foundation.org>, Willy Tarreau <w@....eu>, 
	Thomas Weißschuh <linux@...ssschuh.net>, Brendan Higgins <brendan.higgins@...ux.dev>, 
	David Gow <davidgow@...gle.com>, Rae Moar <rmoar@...gle.com>, Shuah Khan <shuah@...nel.org>, 
	Jonathan Corbet <corbet@....net>, Nicolas Schier <nicolas.schier@...ux.dev>, 
	Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, 
	Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>, 
	Christophe Leroy <christophe.leroy@...roup.eu>, linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org, 
	linux-kselftest@...r.kernel.org, kunit-dev@...glegroups.com, linux-doc@...r.kernel.org, 
	linux-riscv@...ts.infradead.org, workflows@...r.kernel.org
Subject: Re: [PATCH v3 07/16] kbuild: introduce blob framework

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