Messages in this thread | | | Date | Thu, 27 Apr 2006 13:17:55 -0700 | From | "Randy.Dunlap" <> | Subject | Re: checklist (Re: 2.6.17-rc2-mm1) |
| |
On Thu, 27 Apr 2006 13:11:00 -0700 Andrew Morton wrote:
> "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.
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |