Re: checklist (Re: 2.6.17-rc2-mm1)

[Randy.Dunlap]

On Thu, 27 Apr 2006 13:11:00 -0700 Andrew Morton wrote:

> "Randy.Dunlap" <rdunlap@xxxxxxxxxxxx> 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.

Yes, I know/agree.  This is basically what I do (and hope others
would do) for larger patches, not smallish ones.


> 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

Yep, all good, of course.

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