On Tue, 6 May 2008 00:07:12 +0300
Adrian Bunk <bunk@kernel.org> wrote:

quoted text
> On Mon, May 05, 2008 at 01:42:52PM -0700, Andrew Morton wrote:
> > On Mon, 5 May 2008 22:19:06 +0200
> > Ingo Molnar <mingo@elte.hu> wrote:
> > 
> > > Firstly, the practical problem: today "make namespacecheck" emits way 
> > > too many false positives even on an allyesconfig build
> > 
> > We don't actually care about what comes out of `make namespacecheck'.  We
> > care about the _difference_ in its output when a patch is applied.
> > 
> > So a script which reports on what changes a particular patch has upon
> > namespacecheck output might be the way to go.  If it is fast enough then it
> > can be run on a per-patch basis alongside checkpatch.
> 
> "make namespacecheck" works on the binary objects.
> 
> - touching header files can result in a complete rebuild
> - if a patch alters which objects get built you should start with
>   a clean object dir
> 
> The question is therefore basically whether a complete rebuild of an
> all*config kernel is fast enough for you...
> 

That would be quite a bother.

I do think that we should aim to get these things fixed _before_ the
offending patches get into mainline.  It's dopey to append a sprinkle of
fixups against any particular patch after it has hit mainline when we have
the tools to fix those things up beforehand.

And it'd help to educate submitters to check their own stuff.  So when
these post-facto fixups are prepared then it is good to rub people's
noses^W^W^Wgently remind submitters about the problems in their work.
Probably you are already doing this.



Actually, we could perhaps do a lot of this at the checkpatch level?  If
checkpatch sees a global symbol being added and the same patch does not add
references to that symbol from a different file then whine.  Obviously this
will generate false positives but that's OK.
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/