[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090114201513.GC1556@uranus.ravnborg.org>
Date: Wed, 14 Jan 2009 21:15:13 +0100
From: Sam Ravnborg <sam@...nborg.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Jaswinder Singh Rajput <jaswinderlinux@...il.com>,
Jaswinder Singh Rajput <jaswinder@...radead.org>,
Ingo Molnar <mingo@...e.hu>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
David Miller <davem@...emloft.net>,
x86 maintainers <x86@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
netdev <netdev@...r.kernel.org>
Subject: Re: [PULL -tip] fixed few make headers_check warnings
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@...nborg.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists