From: Arjan van de Ven <arjan@infradead.org>
To: "Randy.Dunlap" <rdunlap@xenotime.net>
Cc: Ingo Molnar <mingo@elte.hu>, Adrian Bunk <bunk@kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Sam Ravnborg <sam@ravnborg.org>,
Alexander Viro <viro@ftp.linux.org.uk>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [rfc] the kernel workflow & trivial "global -> static" patches (was: Re: [2.6 patch] make sched_feat_{names,open} static)
Date: Mon, 5 May 2008 14:51:32 -0700 [thread overview]
Message-ID: <20080505145132.58df7e70@infradead.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0805051327530.27703@shark.he.net>
On Mon, 5 May 2008 13:40:53 -0700 (PDT)
"Randy.Dunlap" <rdunlap@xenotime.net> 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...
next prev parent reply other threads:[~2008-05-05 21:52 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-05 18:29 [2.6 patch] make sched_feat_{names,open} static Adrian Bunk
2008-05-05 20:19 ` [rfc] the kernel workflow & trivial "global -> static" patches (was: Re: [2.6 patch] make sched_feat_{names,open} static) Ingo Molnar
2008-05-05 20:40 ` Randy.Dunlap
2008-05-05 21:51 ` Arjan van de Ven [this message]
2008-05-05 23:19 ` david
2008-05-05 23:40 ` Arjan van de Ven
2008-05-05 23:45 ` Theodore Tso
2008-05-06 3:23 ` Arjan van de Ven
2008-05-06 5:48 ` Arjan van de Ven
2008-05-05 20:42 ` Andrew Morton
2008-05-05 21:07 ` Adrian Bunk
2008-05-05 21:26 ` Andrew Morton
2008-05-05 21:45 ` Adrian Bunk
2008-05-05 21:46 ` Arjan van de Ven
2008-05-06 7:46 ` Andy Whitcroft
2008-05-05 21:02 ` Adrian Bunk
2008-05-06 0:21 ` [rfc] the kernel workflow & trivial "global -> static" patches Andi Kleen
2008-05-06 6:18 ` Adrian Bunk
2008-05-06 11:13 ` Andi Kleen
2008-05-06 11:25 ` Adrian Bunk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080505145132.58df7e70@infradead.org \
--to=arjan@infradead.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=bunk@kernel.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rdunlap@xenotime.net \
--cc=sam@ravnborg.org \
--cc=torvalds@linux-foundation.org \
--cc=viro@ftp.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox