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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.