Re: [PATCH 13/17] regulator: stm32-pwr: remove MODULE_LICENSE in non-modules

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

On 3 Mar 2023, Mark Brown outgrape:

> On Thu, Mar 02, 2023 at 09:17:55PM +0000, Nick Alcock wrote:
>> Since commit 8b41fc4454e ("kbuild: create modules.builtin without
>> Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations
>> are used to identify modules. As a consequence, uses of the macro
>
> You've not copied me on the rest of the series so I'm not sure
> what's going on with dependencies.  What's the story here?

There are no interdependencies in this monster: it's just a pile of
individual tiny machine-generated patches, all doing the exact same
thing, and if and when they all make it in the invariant will finally
hold that all modules shown as 'tristate' in Kconfig will have .modinfo
in the resulting vmlinux when built in to the kernel, and
modules.builtin will report them as built-in; and nothing which is *not*
tristate will be reported in modules.builtin as a built-in module.
That's it.

(I don't expect them to all make it in in the first attempt, but I have
a checker which I'll run to figure out which ones didn't make it in and
try to deal with them, and run later at intervals to figure out if we
regress and fix any regressions. The only likely type of regression is
MODULE_LICENSE creeping into non-modules, because things that *can* be
built as modules that don't have a MODULE_LICENSE cause more fallout and
are spotted much faster.)

(This is clearing the way for a later patch which will have
interdependencies, but which is thankfully confined to a single
subsystem so everyone else can ignore it. It happens to need accurate
builtin module info at kallsyms-generation time, and this is the way
Luis wants that done.)

> When sending a patch series it is important to ensure that all
> the various maintainers understand what the relationship between
> the patches as the expecation is that there will be
> interdependencies.  Either copy everyone on the whole series or
> at least copy them on the cover letter and explain what's going
> on.  If there are no strong interdependencies then it's generally
> simplest to just send the patches separately to avoid any
> possible confusion.

The cover letter was sent to every related mailing list (or at least it
was for patch series 2 and 5+: scripting problems blocked 3 and 4,
sorry), which is what the LWN article on big patch series which I'm
following recommended: <https://lwn.net/Articles/585782/>. I didn't want
to spam actual maintainers with more info than that, since presumably
they follow related-according-to-maintainer.pl lists anyway.

As for copying everyone on a 121-patch monster like this... well, I
think everyone would have wanted to throttle me, and I'm not sure they'd
have been wrong.


Originally I did this whole thing as one massive patch, but I was asked
to split it up by subsystem. This yielded 121 tiny patches with distinct
subsystems and Cc: sets. Sending a 121-patch series was my original plan
but we talked to people first and they all said rough equivalents of
'god, no' and suggested splitting it up into a bunch of shorter
mini-series to reduce the load on people's mailboxes and brains.

I don't think anyone has previously suggested making it 121 individual
patches with no cover letter whatsoever. As it is, those series that
accidentally went out without cover letters properly Cc:ed confused some
maintainers because of the lack of the cover letter. My apologies.

It does seem this is an area where I can't please everyone. Some people
don't want to be Cc:ed, others want everyone Cc:ed on all of them: some
people want series, others want individual patches for everyone. I can't
do both. Sorry about that.