Jeff,
Jeff Garzik wrote:
> The tool which I envision need only handle simple stuff at first. As
> long as the source code analyzer knows C code at a semantic level, I
> need only write extra rules / regexes to catch basic but very common
> driver code errors.
>
> It is too much to ask "kernel-lint" to puzzle through page cache flag
> arcana for example, but I can think of a ton of simple things that a
> kernel-lint tool could scan for that would be useful..
> * divide by power of two, instead of shifting
> * calling pci_find_xxx functions without pci_enable_device somewhere in
> the driver
> * calling MOD_INC_USE_COUNT in a function AFTER a call to request_irq or
> a similar function which may sleep
> [...]
>
> It's still a tall order to handle simple stuff like this.. Further, it
> is granted that all rules are generally broken for a good reason at
> least once. but such a tool IMHO would be invaluable to people
> maintaining kernel drivers.
That's a really good idea. And it's not only useful for people
maintaining things, but also for newbies trying to get work done but
have no idea (yet)(like me, still).
Perhaps you could start writing down the rules? Or are those already
written down somewhere?
-- Jan Evert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 30 2000 - 21:00:09 EST