Message-ID: <8735kqswxc.fsf@esperi.org.uk>
Date:   Thu, 10 Feb 2022 12:55:43 +0000
From:   Nick Alcock <nick.alcock@...cle.com>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     "Luis R. Rodriguez" <mcgrof@...nel.org>,
        Jiri Olsa <jolsa@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>, bas@...lab.org,
        tglozar@...il.com, Ast-x64@...tonmail.com, viktor.malik@...il.com,
        Daniel Xu <dxu@...uu.xyz>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Ian Rogers <irogers@...gle.com>,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        linux-modules <linux-modules@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Eugene Loh <eugene.loh@...cle.com>,
        Kris Van Hees <kris.van.hees@...cle.com>
Subject: Re: [PATCH v8 2/6] kbuild: add modules_thick.builtin

On 10 Feb 2022, Masahiro Yamada told this:

> On Wed, Feb 9, 2022 at 3:44 AM Nick Alcock <nick.alcock@...cle.com> wrote:
>>
>> I am not wedded to the approach used to construct this file, but I don't
>> see any other way to do it despite spending a week or so trying to tie
>> it into Kbuild without using a separate Makefile.modbuiltin: unlike the
>> names of builtin modules (which are also recorded in the source files
>> themseves via MODULE_*() macros) the mapping from object file name to
>> built-in module name is not recorded anywhere but in the makefiles
>> themselves, so we have to at least reparse them with something to
>> indicate the builtin-ness of each module (i.e., tristate.conf) if we are
>> to figure out which modules are built-in and which are not.
>>
>> Signed-off-by: Nick Alcock <nick.alcock@...cle.com>
>> Reviewed-by: Kris Van Hees <kris.van.hees@...cle.com>
>
> modules.builtin was initially implemented in a terrible way,
> hence I cleaned up the code and removed the double recursion
> of the source tree.

That's why I said I was not wedded to this approach, and I'd be happy
to use another one.

I tried to reimplement it using a single recursion, but it seems to be
impossible or at least very difficult, since you have to somehow
interpret each target in the tree in two ways ("build this" versus
"figure out whether this is built-in or not): if you can think up a
trick, I'll give it a try. I tried to make the core Kbuild makefiles
interpret obj-Y suitably, which might mean you could build the whole
tree with tristate.conf in force as it is in Makefile.modbuiltin, but
got lost in the tangle: and in any case doing that seemed far more
invasive and far more likely to be rejected than just bringing back
Makefile.modbuiltin.

But for now, to me, this seems tolerable. The time costs of building
modules_thick.builtin are so minimal I cannot determine them in a normal
parallel build, well down in the noise, unless your machine is so short
of memory that it can't even cache the directory tree walk (and with the
cache hot, even with -j 1 building it takes only half a second). The
maintenance costs appear to be basically zero as well: one file, not
tightly coupled to the rest (the only coupling it has is the same
coupling as every makefile in the build tree). Also one file that was
present for decades already :)

So... honestly, I don't see your objection. What's terrible about
scripts/Makefile.modbuiltin? If it's so terrible, do you have an
alternative way to do what it does in this patch series?

> Honestly, I do not want to see you bringing back
> all the bloat.

It's come back because I find it necessary for the series which follows,
which surely makes it not bloat. If you can think of another approach
that can similarly figure out which modules are built in and which are
not, I'd be happy to use it, but I can't think of one.

Powered by blists - more mailing lists