From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Kai Vehmanen <kai.vehmanen@linux.intel.com>,
Filipe Brandenburger <filbranden@google.com>,
Greg Thelen <gthelen@google.com>,
Michael Davidson <md@google.com>,
Eugene Surovegin <surovegin@google.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Michal Marek <michal.lkml@markovi.net>,
Jonathan Corbet <corbet@lwn.net>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>
Subject: Re: [PATCH] modpost: allow modpost to fail on warnings
Date: Thu, 24 Sep 2020 13:13:35 -0500 [thread overview]
Message-ID: <c9d19777-9027-0bb6-8590-1bfeac14b33f@linux.intel.com> (raw)
In-Reply-To: <CAK7LNAQfm5GVH93zAJakB1JpyS1qf93qTUETofOstSJ9jcky3w@mail.gmail.com>
>>> I think [1] should be an error instead of a warning
>>> by default.
>>
>> would the following patch be what you have in mind?
>
>
> No.
> error() does not exist.
>
> merror() exists, but the difference from warn()
> is just a prefix.
>
> If any error happens, modpost should return the error code.
Sorry, I am not able to understand your recommendation. Existing code
which calls merror() does not exit with an error code, e.g.
static void sym_update_namespace(const char *symname, const char *namespace)
{
struct symbol *s = find_symbol(symname);
/*
* That symbol should have been created earlier and thus this is
* actually an assertion.
*/
if (!s) {
merror("Could not update namespace(%s) for symbol %s\n",
namespace, symname);
return;
}
What would be suggestion be then in this case?
change all functions to return -EINVAL after each use of merror() or
something?
Or just add an exit(1) after all uses of merror()?
>> If yes, also wondering if we can still add the option to treat warnings
>> as errors as an opt-in behavior?
>
>
> I want to add a new option only when it is necessary to do so.
>
> I am not sure which warnings are real warnings.
That was the point of the suggested option, treat all warnings as errors
and ignore the warning if it's no big deal. it's standard with gcc
-Werror, it's be good to extend this to modpost - or what would be the
drawback of doing so?
prev parent reply other threads:[~2020-09-24 18:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-18 21:50 Pierre-Louis Bossart
2020-09-19 6:21 ` Masahiro Yamada
2020-09-21 14:50 ` Pierre-Louis Bossart
2020-09-24 17:22 ` Masahiro Yamada
2020-09-24 18:13 ` Pierre-Louis Bossart [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=c9d19777-9027-0bb6-8590-1bfeac14b33f@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=corbet@lwn.net \
--cc=filbranden@google.com \
--cc=gthelen@google.com \
--cc=kai.vehmanen@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=md@google.com \
--cc=michal.lkml@markovi.net \
--cc=sfr@canb.auug.org.au \
--cc=surovegin@google.com \
/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
all inboxes | Powered by JetHome®