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

From: Adrian Bunk
Date: Mon May 05 2008 - 17:46:55 EST


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@xxxxxxxxxx> 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@xxxxxxx> 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/