Re: [rfc] the kernel workflow & trivial "global -> static" patches (was: Re: [2.6 patch] make sched_feat_{names,open} static)

[Adrian Bunk <bunk@kernel.org>]

On Mon, May 05, 2008 at 02:26:04PM -0700, Andrew Morton wrote:
> On Tue, 6 May 2008 00:07:12 +0300
> Adrian Bunk <bunk@kernel.org> wrote:
> 
> > 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.

Not sure what is possible at the checkpatch level.

Adding -Wmissing-prototypes to the CFLAGS (which was my original 
motivation for doing these patches) would help much, but it's still a 
long road until I can propose it without being lynched for the warnings 
it still generates...

Or teach people to use sparse?

After all, this thread erupted on a patch against kernel/sched.c
that fixes something sparse also warns about.

I just tried running sparse against this file - looks scary...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed