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


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