From: Andrew Morton <akpm@osdl.org>
To: "Randy.Dunlap" <rdunlap@xenotime.net>
Cc: ak@suse.de, linux-kernel@vger.kernel.org
Subject: Re: checklist (Re: 2.6.17-rc2-mm1)
Date: Thu, 27 Apr 2006 13:11:00 -0700 [thread overview]
Message-ID: <20060427131100.05970d65.akpm@osdl.org> (raw)
In-Reply-To: <20060427124452.432ad80d.rdunlap@xenotime.net>
"Randy.Dunlap" <rdunlap@xenotime.net> wrote:
>
>
> > > So at this point in time what I'd like to do is to encourage developers to
> > > do these very basic things. That's the low-hanging fruit right now.
> >
> > Write a checklist for that?
>
> I've been meaning to write up one myself, so I'll give it a shot.
>
> This is all above and beyond good patch log descriptions.
>
>
> 1. Build cleanly with applicable or modified CONFIG options =y, =m, and =n.
> No gcc warnings/errors, no linker warnings/errors.
>
> 2. Build on multiple CPU arch-es by using local cross-compile tools
> or something like PLM at OSDL.
>
> 3. Check cleanly with sparse.
>
> 4. Make sure that any new or modified CONFIG options don't muck up
> the config menu.
>
> 5. Use 'make checkstack' and 'make namespacecheck' and fix any
> problems that they find. Note: checkstack does not point out
> problems explicitly, but any one function that uses more than
> 512 bytes on the stack is a candidate for change.
>
> 6. Include kernel-doc to document global kernel APIs. (Not required
> for static functions, but OK there also.) Use 'make htmldocs'
> or 'make mandocs' to check the kernel-doc and fix any issues.
>
A lot of these are pretty hard and labor-intensive for people to set up and
run. It would be nice, but from a global perspective it's not efficient
for every member of the kernel team to do all these things. It's OK I
think if a few specialists run these tools against lots of people's patches
all at once.
Which is basically what we're doing now, although I suspect we could be
more rigorous about it.
I should be doing more of these things myself, but it's plenty enough work
getting though the "applies, doesn't-ridicule-coding-style,
compiles-without-warnings, boots-on-several-arches" steps. It's good that
Adrian does some of the other steps. I'm not aware of anyone who is doing
regular sparse and kernel-doc checking on -mm.
That all being said, these are all good things to have in a list.
To your list I'd add
- Passes allnoconfig, allmodconfig
- Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_SLAB,
CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK,
CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously enabled.
- Has been build- and runtime tested with and without CONFIG_SMP and
CONFIG_PREEMPT.
- If it affects IO/Disk, etc: has been tested with and without CONFIG_LBD.
- ppc64 is a good architecture for cross-compilation checking because it
tends to use `unsigned long' for 64-bit quantities.
- Has been carefully reviewed wrt relevant Kconfig combinations. This is
very hard to get right with testing - brainpower pays off here.
- Matches kernel coding style(!)
- All new Kconfig options have help text
next prev parent reply other threads:[~2006-04-27 20:08 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-27 8:41 2.6.17-rc2-mm1 Andrew Morton
2006-04-27 10:16 ` 2.6.17-rc2-mm1 Andi Kleen
2006-04-27 19:19 ` 2.6.17-rc2-mm1 Andrew Morton
2006-04-27 19:26 ` 2.6.17-rc2-mm1 Andi Kleen
2006-04-27 19:44 ` checklist (Re: 2.6.17-rc2-mm1) Randy.Dunlap
2006-04-27 20:11 ` Andrew Morton [this message]
2006-04-27 20:17 ` Randy.Dunlap
2006-04-27 20:36 ` Martin Bligh
2006-04-27 19:56 ` Andi Kleen
2006-04-27 21:00 ` Martin Bligh
2006-04-27 20:11 ` Andi Kleen
2006-04-27 21:22 ` Martin Bligh
2006-04-28 17:30 ` Rafał J. Wysocki
2006-04-27 21:00 ` Christoph Hellwig
2006-04-28 14:03 ` Paulo Marques
2006-04-28 15:22 ` Jan Engelhardt
2006-05-01 21:20 ` Valerie Henson
2006-05-01 21:35 ` Martin Bligh
2006-05-01 23:11 ` Valerie Henson
2006-04-27 20:52 ` Jan Dittmer
2006-04-27 21:01 ` Randy.Dunlap
2006-04-27 21:41 ` 2.6.17-rc2-mm1 Grant Coady
2006-04-27 21:50 ` 2.6.17-rc2-mm1 Randy.Dunlap
2006-04-27 22:16 ` 2.6.17-rc2-mm1 Andrew Morton
2006-04-27 10:27 ` 2.6.17-rc2-mm1 Michal Piotrowski
2006-04-27 13:07 ` 2.6.17-rc2-mm1 Michal Piotrowski
2006-04-27 15:28 ` 2.6.17-rc2-mm1 Greg KH
2006-04-27 15:32 ` 2.6.17-rc2-mm1 Michal Piotrowski
2006-04-27 20:53 ` 2.6.17-rc2-mm1 Greg KH
2006-04-27 22:09 ` 2.6.17-rc2-mm1 Michal Piotrowski
2006-04-27 15:26 ` 2.6.17-rc2-mm1 Greg KH
2006-04-27 15:43 ` 2.6.17-rc2-mm1 Michal Piotrowski
2006-04-27 15:01 ` 2.6.17-rc2-mm1: ACPI_DOCK=n, HOTPLUG_PCI_ACPI=y compile error Adrian Bunk
2006-04-27 15:47 ` 2.6.17-rc2-mm1 Matthieu CASTET
2006-04-27 18:02 ` 2.6.17-rc2-mm1 Vivek Goyal
2006-04-27 23:24 ` 2.6.17-rc2-mm1 Greg KH
2006-04-28 14:40 ` 2.6.17-rc2-mm1 Vivek Goyal
2006-04-28 16:07 ` 2.6.17-rc2-mm1 matthieu castet
2006-04-28 18:05 ` 2.6.17-rc2-mm1 Vivek Goyal
2006-04-27 17:57 ` [-mm patch] fix VIDEO_DEV=m, VIDEO_V4L1_COMPAT=y Adrian Bunk
2006-04-27 18:17 ` Andrew Morton
2006-04-27 20:15 ` Mauro Carvalho Chehab
2006-04-27 18:00 ` [-mm patch] fs/nfs/inode.c: make nfs_follow_referral() Adrian Bunk
2006-04-27 18:03 ` [-mm patch] mm/vmscan.c: make shrink_all_zones() static Adrian Bunk
2006-04-27 18:52 ` Rafael J. Wysocki
2006-04-27 20:33 ` [-mm patch] fs/gfs2/: possible cleanups 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=20060427131100.05970d65.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rdunlap@xenotime.net \
/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