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

[Arjan van de Ven]

On Mon, 5 May 2008 16:19:13 -0700 (PDT)
david@xxxxxxx wrote:

> 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? 

only some; if the output is a filename/linenumber (and some message) we
can always do "git blame" on when it changed last.
Heck we could then automate to run at that point again to see if that
patch really caused it (similar to bisect but a lot more targeted).

This of course breaks if you do it once a year... but if you do it
"small enough" it shouldn't be that bad... even during a merge window
it'll be fine.
--
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/