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

[david]

On Mon, 5 May 2008, Arjan van de Ven wrote:

> On Mon, 5 May 2008 13:40:53 -0700 (PDT)
> "Randy.Dunlap" <rdunlap@xxxxxxxxxxxx> wrote:
>
> > On Mon, 5 May 2008, Ingo Molnar wrote:
> >
> > > And unlike other kernel developers, my opinion is not that we
> > > should eliminate this disruption by not doing these trivial patches
> > > _at all_. My opinion is that we should make it easier for
> > > maintainers to _avoid introducing_ these problems.
> > >
> > > I.e. we need to fight the root of this problem (the steady
> > > introduction of needlessly global symbols), not its symptoms (the
> > > needlessly global symbols themselves).
> >
> > in some automated ways...
> >
> > We have Documentation/SubmitChecklist that we hope that patch
> > submitters will use, but we have little evidence that they (we) do
> > use it, and we have some evidence that they (we) do NOT use it.
> > (but this isn't automated)
> >
> > I see being related to DaveM's "Slow down, please" thread.
> > We have developers hurriedly writing new code but not paying enough
> > attention to code that they have already written.
> > (not directed at anyone in particular)
> >
> > E.g., you do maybe 200 randconfig builds per day.  I only do
> > 20 - 50, but we both find too many problems (IMHO).
> >
> > > Let me raise some thoughts about what we could do to achieve these
> > > goals.
> >
> > Good discussion material.
>
>
> can we do a "make patchcheck" kernel build target that would
> * run checkpatch on teh patch
> * build the kernel without the patch (in various .configs, probably
> allyesconfig / allmodconfig is enough, but we can figure this out
> later)
> * apply the patch
> * build the kernel in the same configs
> * build a kernel for install that has the 'standard debug options' on
>  (lockdep, slabpoison etc)
> then we can
> * compare if new gcc warnings got introduced
> * compare if major stack usage got introduced
> * compare if namespace_check and some of the others introduce new issues
> * compare if new sparse warnings got introduced
> and maybe even run a bloat-o-meter to show code growth/shrinkage
> [insert other useful checks here]
>
> if all of that is just one command away, I bet quite a few people would
> use it
> (and the more useful it gets the more people will use it)
>
> yes you can do the same thing by hand.
> but yes it's many steps that are cumbersome if not automated... so few
> people will do it.
>
> If it's all in one step...

keep listing the checks you want to have done. I'll bet that if you can 
automate it enough you will have people setting up farms to do the 
compiles (or, ideally, package it with a seti-at-home type of thing and 
many people will donate spare cycles to grinding away at it)

how much value is lost if this is run on larger chunks? during the merge 
window the number of patches will exceed anyone's capability to check each 
one individually (not to mention it being a little late), but I think 
there would still be value in checking larger groups of patches.

David Lang
--
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/