public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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



  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