lkml.org 
[lkml]   [2006]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2006-04-27 22:17    [W:0.027 / U:0.192 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site