From: William McVicker <willmcvicker@google.com>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Nicolas Schier <nicolas@fjasle.eu>
Subject: Re: [PATCH] kbuild: do not automatically add -w option to modpost
Date: Tue, 24 Jan 2023 09:39:22 -0800 [thread overview]
Message-ID: <Y9AXytjc61Le0PQZ@google.com> (raw)
In-Reply-To: <CAK7LNASfY+2w-aN0LQs0_gB=ASRyJoXSobsqzGa0BNL2sqpJeA@mail.gmail.com>
On 01/24/2023, Masahiro Yamada wrote:
> On Tue, Jan 24, 2023 at 7:42 AM William McVicker
> <willmcvicker@google.com> wrote:
> >
> > On 01/23/2023, Masahiro Yamada wrote:
> > > When there is a missing input file (vmlinux.o or Module.symvers), you
> > > are likely to get a ton of unresolved symbols.
> > >
> > > Currently, Kbuild automatically adds the -w option to allow module builds
> > > to continue with warnings instead of errors.
> > >
> > > This may not be what the user expects because it is generally more useful
> > > to catch all possible issues at build time instead of at run time.
> > >
> > > Let's not do what the user did not ask.
> > >
> > > If you still want to build modules anyway, you can proceed by explicitly
> > > setting KBUILD_MODPOST_WARN=1. Since you may miss a real issue, you need
> > > to be aware of what you are doing.
> > >
> > > Suggested-by: William McVicker <willmcvicker@google.com>
> > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > > ---
> > >
> > > scripts/Makefile.modpost | 8 +++-----
> > > 1 file changed, 3 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
> > > index 43343e13c542..9254ed811ddd 100644
> > > --- a/scripts/Makefile.modpost
> > > +++ b/scripts/Makefile.modpost
> > > @@ -121,16 +121,14 @@ modpost-args += -e $(addprefix -i , $(KBUILD_EXTRA_SYMBOLS))
> > >
> > > endif # ($(KBUILD_EXTMOD),)
> > >
> > > -ifneq ($(missing-input),)
> > > -modpost-args += -w
> > > -endif
> > > -
> > > quiet_cmd_modpost = MODPOST $@
> > > cmd_modpost = \
> > > $(if $(missing-input), \
> > > echo >&2 "WARNING: $(missing-input) is missing."; \
> > > echo >&2 " Modules may not have dependencies or modversions."; \
> > > - echo >&2 " You may get many unresolved symbol warnings.";) \
> > > + echo >&2 " You may get many unresolved symbol errors.";) \
> >
> > You need to move the closing parenthesis to come at the end of these
> > echo messages. Otherwise you get this new message unconditionally.
>
>
> Ah, thanks for catching it.
>
>
> > I also found during testing that the refactoring in commit f73edc8951b2
> > ("kbuild: unify two modpost invocations") dropped the check for missing
> > KBUILD_EXTRA_SYMBOLS. That means if an external module depends on
> > another external module and sets:
> >
> > KBUILD_EXTRA_SYMBOLS=/path/to/ext_module/Module.symvers
> >
> > ... then make will fail even with KBUILD_MODPOST_WARN=1 since we
> > unconditionally add KBUILD_EXTRA_SYMBOLS to the modpost-args like this:
> >
> > modpost-args += -e $(addprefix -i , $(KBUILD_EXTRA_SYMBOLS))
> >
> > To fix this, I suggest you also take the following patch so that
> > KBUILD_MODPOST_WARN=1 will allow you to skip those unresolved symbols as
> > well:
>
>
> How is this useful?
>
> KBUILD_EXTRA_SYMBOLS is explicitly specified by the user
> via the command line or the environment variable.
>
> If $(KBUILD_EXTRA_SYMBOLS) does not exist,
> it is a user's fault, isn't it?
Sort of, yes. One could argue that it's the same situation as missing
the in-tree Module.symvers or the vmlinuux.o/vmlinux.symvers. Basically,
if you keep it as is, then KBUILD_MODPOST_WARN=1 would only work if the
user edits the Makefile to remove the KBUILD_EXTRA_SYMBOLS line. With
my suggested patch, the user could build the module as is without any
dependencies by setting KBUILD_MODPOST_WARN=1.
I'm fine with whichever way you choose to support since I know this is
an external modules edge-case. I personally like to build my modules
with all the dependencies present to try an catch any issues at build
time.
Thanks,
Will
>
>
>
>
>
>
> --
> Best Regards
> Masahiro Yamada
prev parent reply other threads:[~2023-01-24 17:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-23 5:26 [PATCH] kbuild: do not automatically add -w option to modpost Masahiro Yamada
2023-01-23 22:42 ` William McVicker
2023-01-24 2:48 ` Masahiro Yamada
2023-01-24 17:39 ` William McVicker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9AXytjc61Le0PQZ@google.com \
--to=willmcvicker@google.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=nicolas@fjasle.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox