On Thu, 26 Apr 2007 01:30:59 -0700 Andrew Morton wrote:
> On Thu, 26 Apr 2007 02:32:06 +0200 Arnd Bergmann <[email protected]> wrote:
>
> > On Thursday 26 April 2007, Andrew Morton wrote:
> > > It would be neat if someone could create and maintain a new
> > > scripts/spot-common-mistakes. Feed it a unified diff and it would complain
> > > about newly-added code (and only newly-added code) which has busted
> > > whitespace, adds new semaphores, adds new kernel_thread calls, etc, etc.
> >
> > http://patchstylecheck.googlecode.com/svn/trunk/patchstylecheckemail.pl
> > Might serve as a starting point for this. It doesn't have any semantic
> > checks right now, but I guess they can be added.
>
> oh man, every patch I review, every bug I fix, I dream of this.
singing?
> Wishlist:
>
> - wire it up to a robot which monitors all Linux mailing lists and sends
> machine-review comments back to originators. This will be a huge win by
> eliminating so much stupid crap.
>
> - auto-detect wordwrapped and tab-replaced emails (oh glory)
>
> - auto-detect code wider than 80-cols (swoon)
>
> - auto-detect missing Signed-off-by:
>
> - auto-check patch format and protocol, as per
> http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt and
> http://linux.yyz.us/patch-format.html
>
> - teach it about semantics:
>
> - kthread instead of kernel_thread
>
> - mutexes instead of semaphores
>
> - the whole plethora of whitespace uckfuppednesses
>
> - needlessly-initialised-to-zero-static-variables
>
> - extern-decls-in-C
>
> - EXPORT_SYMBOL(foo) is placed immediately after foo()'s closing
> brace
>
> Hard to do? Could just whine about all EXPORT_SYMBOL's which
> aren't immediately preceded by ^}$ or by ;$
>
> - new typedefs
>
> - use of uint32_t and friends
>
> - use of BUG_ON and BUG, frankly. The thing's a damn pest. Suggest
> WARN_ON+recover-from-it.
>
> - use of `if ((var = expr()))' and similar
>
> - large inlined functions?
>
> - braces around single statements (advanced topic ;))
>
> - StudlyCaps?
>
> - anything called "tmp" or "temp"
>
> - old-style struct initialisers
>
> - non-ascii characters(?)
>
> - lots more to come, I'm sure.
I made a short list last night, but yours is better/longer.
Here are a few more items:
- check for new docs and/or kernel-doc
- storage class should be first
- don't use deprecated APIs
- no floating point
- no MIN/MAX
- printk wants KERN_* levels
- limit on new /proc files
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]