mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Jonathan Kliegman <kliegs@chromium.org>
Cc: linux-kernel@vger.kernel.org, Michal Marek <mmarek@suse.cz>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Tony Lindgren <tony@atomide.com>,
	linux-kbuild@vger.kernel.org
Subject: Re: [PATCH] modpost: Add flag -f for making section mismatches fatal
Date: Tue, 8 Jan 2013 20:16:01 +0100	[thread overview]
Message-ID: <20130108191600.GA12563@merkur.ravnborg.org> (raw)
In-Reply-To: <CAPQV+nP1UJP4R8AmoUf4bt873Yz_D0ZR2msaCRx5eAc49QFodA@mail.gmail.com>

On Sun, Jan 06, 2013 at 03:22:39PM -0500, Jonathan Kliegman wrote:
> On Sun, Jan 6, 2013 at 4:36 AM, Sam Ravnborg <sam@ravnborg.org> wrote:
> > Hi Jonathan.
> >
> >> The section mismatch warning can be easy to miss during the kernel build
> >> process.  Allow it to be marked as fatal to be easily caught and prevent
> >> bugs from slipping in.
> >>
> >> Signed-off-by: Jonathan Kliegman <kliegs@chromium.org>
> >
> > Another way to make them much more visible would be to make
> > the warnings always be verbose.
> 
> I'd like to keep the option for a hard fail if a mismatch is detected.
>  This way automated build systems will detect the failed build and can
> reject a chan
> 
> > In other words drop support for the "-S" options used below:
> >>   $(if $(CONFIG_DEBUG_SECTION_MISMATCH),,-S)
> >
> > Previously the dev* stuff caused a lot of warnings, but
> > since we have HOTPLUG always enabled this is a non-issue.
> > So I think that this is a good time to enable the verboce
> > warnings.
> I can submit a second patch for this if you'd like, but I'm not
> familiar with all the previous decisions in this area.  If I
> understand correctly we'll still need the config option as it also
> changes compiler flags for inlining.

Correct.
We need one config option that allows us to debug section mismatchs.
This options adds another gcc option as you also points out.
And this is the one that already exist.

And then you suggest to add another options which makes section
mismatch warnings fatal.
This sounds like a good idea but reverse the logic.
Something like:

   CONFIG_SECTION_MISMATCH_WARN
	bool "Section mismatch warnings produced by modpost are non-fatal"
	default y
	help
	  bla bla

Because then you do not cause section mismatch to be fatal for allyesconfig and
allmodconfig builds. We really do not want to go there yet (I think).
I must admit I do not know how many section mismatch warnigns that are lingering
for the different architectures.
If the number is sufficiently low then we could consider go for fatal as default.


And it would be good to have first patch that makes section mismatch warnings verbose,
independent on any config options.

This patch would have to do something like:
- Makes it possible to set CONFIG_DEBUG_SECTION_MISMATCH using menuconfig (I recall there are
  a dependency that avoids this today)
- Drop support for the -S options and drop the bits that set it
- Drop the reference to CONFIG_DEBUG_SECTION_MISMATCH in modpost error message

I would be happy if you could do this and test it.

	Sam

  reply	other threads:[~2013-01-08 19:16 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-20 18:49 Jonathan Kliegman
2013-01-02 23:56 ` Rusty Russell
2013-01-03  9:06   ` Michal Marek
2013-01-03 21:39     ` Jonathan Kliegman
2013-01-12 21:24       ` Michal Marek
2013-01-06  9:36 ` Sam Ravnborg
2013-01-06 20:22   ` Jonathan Kliegman
2013-01-08 19:16     ` Sam Ravnborg [this message]
2013-01-08 19:38       ` Jonathan Kliegman
2013-01-08 19:39         ` Sam Ravnborg
2015-10-02  0:34 Nicolas Boichat
2015-10-02  1:26 ` Rusty Russell

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=20130108191600.GA12563@merkur.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kliegs@chromium.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=rusty@rustcorp.com.au \
    --cc=tony@atomide.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®