Re: [PATCH 21/27] kbuild, dma-mapping: benchmark: remove MODULE_LICENSE in non-modules

[Nick Alcock <nick.alcock@oracle.com>]

On 23 Feb 2023, Luis Chamberlain outgrape:

> On Thu, Feb 23, 2023 at 03:31:50PM +0000, Nick Alcock wrote:
>> Nor can I -- and more generally I can't figure out a way to get from the
>> Kconfig symbols to the source files that constitute them without
>> retraversing the tree, since the only place the relationship is recorded
>> is in makefiles, and those makefiles use a lot of make functionality
>> (including more or less arbitrary make functions).
>
> $ grep "_MODULE 1" ./include/generated/autoconf.h| wc -l
> 560
>
> $ grep "_MODULE 1" ./include/generated/autoconf.h| grep XFS
> #define CONFIG_XFS_FS_MODULE 1
>
> I *think* the trick will likely be to have new a possibilities.h or just
> agument autoconf.h with POSSIBLE_MODULE for each module.
>
> The next complexity lies in inferring the license and doing the license
> output given a combination. I *think* you already figured out the objs
> from the module, and in fact your new kallsyms extension I think prints
> these out right (which I find highly useful)?

Oh, of course, I forgot about that (how stupid of me). Of course the
double-traversal is only necessary if we're trying to *compare* the
results of tristate in Kconfig with the result of the modinfo objs=: if
we assume the modinfo objs= is right (which it should be in the end), we
can just rely on it and then we don't need to double-traverse after all,
except when verifying that (which is a rare intermittent maintenance
task).

(Of course, kallmodsyms elides all objnames that aren't necessary for
symbol disambiguation and reduces the length of what it keeps as far as
it can, but I'm open to an option that just stores the lot, unelided: it
would eat ~750KiB in the kernel image for all but very small kernels,
but for debugging that's fine. Saving more space than that requires
storing the things in a per-path-component tree or something, and would
likely still eat >500K because the leaves are extremely numerous.)

>                                               If so then we use these as
> input source for an SPDX license lookup. Instead of having this
> relationship grep'd after at build time, I wonder if might be good to
> just collect all license associates to all files in a header file
> similar to _MODULE prefix so maybe SPDX_$(file_path)_LICENSE_$license
> which creates a header file 1-1 mapping.
>
> Not sure if that's too much noise.
>
> Just a thought, to get the wheels spinning.

The only problem that I can see with that is that this stops us using
MODULE_LICENSE for modinfo construction, since right now things like the
objs= and the module name are dependent on per-module #defines passed in
via -D, which obviously can only have one value while compiling a single
file. But it would be perfectly doable to rename MODULE_LICENSE() to
something like a zero-arg MODULE_INFO() and relieve it of the
responsibility for setting the license, so we could put the license info
into a single file as you suggest. Non-builtin modules could just stuff
a single MODULE_LICENSE line in the mod.c.

-- 
NULL && (void)