From: Sam Ravnborg <sam@ravnborg.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Jaswinder Singh Rajput <jaswinderlinux@gmail.com>,
Jaswinder Singh Rajput <jaswinder@infradead.org>,
Ingo Molnar <mingo@elte.hu>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
David Miller <davem@davemloft.net>,
x86 maintainers <x86@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
netdev <netdev@vger.kernel.org>
Subject: Re: [PULL -tip] fixed few make headers_check warnings
Date: Wed, 14 Jan 2009 21:15:13 +0100 [thread overview]
Message-ID: <20090114201513.GC1556@uranus.ravnborg.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0901141732450.26663@anakin>
On Wed, Jan 14, 2009 at 05:36:14PM +0100, Geert Uytterhoeven wrote:
> On Wed, 14 Jan 2009, Jaswinder Singh Rajput wrote:
> > On Wed, Jan 14, 2009 at 9:08 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
> > > I appreciate your work but I will like to question the approach.
> >
> > My approach was:
> > "PATCH should solve a problem per file", like:
> > capability.h: extern's make no sense in userspace
> > coda_psdev.h: extern's make no sense in userspace
> > in6.h: extern's make no sense in userspace
> > nubus.h: extern's make no sense in userspace
> > socket.h: extern's make no sense in userspace
> >
> > But this warnings was in many files:
> > include of <linux/types.h> is preferred over <asm/types.h> : 15 files
> > found __[us]{8,16,32,64} type without #include <linux/types.h> : 52 files
> >
> > So in place of making 15 + 52 = 67 patches, I made 2 patches for each warning.
> >
> > > We should rather take the warnings as an indication that this
> > > file needs to be looked over and fix not only the warnings
> > > reported but rater to fix all the questionable issues on a file-by-file basis.
> >
> > Should I make 67 patches ?
>
> No.
>
> What Sam means is that the warnings about externs not making sense in userspace
> are indicators that there may be other external declarations (without "extern")
> in those files, and that you should fix those at the same time (i.e. either
> don't fix any of them, or fix all of them (in the same file)). If you don't
> fix them at the same time, people tend to forget about them.
>
> So the warnings are just considered canaries in our coal mine. Killing only the
> canaries doesn't help.
Correct. We should use the warnings to tell us that there may be something
fishy here and fix it all.
I've used checkpatch in the same way occasionally. If I had to do some
cleanup and checkpatch was a bit noisy I went through the file
_manually_. And when finished I ran chackpatch again and fixed up the
warnings/errors that made sense for me to fix and that I forgot when I refactored
the code.
So when I see "capability.h: extern's make no sense in userspace"
the perfect approach would be that the whole file was checked.
This is a much bigger task that just removing the warning.
(All this said I have sometimes doen the "remove warnings only trick too").
Sam
next prev parent reply other threads:[~2009-01-14 20:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 8:40 [PULL -tip] fixed few make headers_check warnings Jaswinder Singh Rajput
2009-01-13 12:49 ` Ingo Molnar
2009-01-13 21:03 ` David Miller
2009-01-14 15:40 ` Sam Ravnborg
2009-01-14 15:58 ` Oliver Hartkopp
2009-01-15 10:54 ` Ingo Molnar
2009-01-14 8:56 ` Geert Uytterhoeven
2009-01-14 9:29 ` Jaswinder Singh Rajput
2009-01-14 15:38 ` Sam Ravnborg
2009-01-14 15:59 ` Jaswinder Singh Rajput
2009-01-14 16:36 ` Geert Uytterhoeven
2009-01-14 16:58 ` Jaswinder Singh Rajput
2009-01-14 20:15 ` Sam Ravnborg [this message]
2009-01-15 11:11 ` Ingo Molnar
2009-01-15 14:37 ` Sam Ravnborg
2009-01-15 14:47 ` Jaswinder Singh Rajput
2009-01-15 14:50 ` Ingo Molnar
2009-01-15 14:51 ` Ingo Molnar
2009-01-15 15:16 ` Jaswinder Singh Rajput
2009-01-15 15:33 ` Ingo Molnar
2009-01-15 14:49 ` Ingo Molnar
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=20090114201513.GC1556@uranus.ravnborg.org \
--to=sam@ravnborg.org \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davem@davemloft.net \
--cc=geert@linux-m68k.org \
--cc=jaswinder@infradead.org \
--cc=jaswinderlinux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=x86@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).