Re: [PATCH] checkpatch: Test for kmalloc/memset(0) pairs

[Ingo Molnar]

* Julia Lawall <julia@xxxxxxx> wrote:

> On Sun, 20 Mar 2011, Pekka Enberg wrote:
> 
> > Hi Julia,
> > 
> > On Sun, Mar 20, 2011 at 10:01 AM, Julia Lawall <julia@xxxxxxx> wrote:
> > > Suggestions for how to make it easier to use or the documentation more
> > > understandable are welcome.
> > 
> > The benefit of scripts/checkpatch.pl is that it doesn't require any
> > setting up to do. I'm personally less likely to use Coccinelle (and
> > Sparse for that matter) on boxes where the software is not installed.
> > I'm not sure how other people feel about it, but I'd personally love
> > to see tools/coccinelle and tools/sparse.
> 
> This was discussed before, and it was felt that perhaps 75000 lines of 
> ocaml code was not really appropriate for the Linux source tree, [...]

We have drivers and rare architectures that have a (much) larger size and which 
are only useful to <0.01% of Linux users.

Coccinelle on the other hand is useful to 100% of Linux users.

We even have C++, perl and python code in the kernel repo so there's no 
language bigotry either - use the language that works best for your project.

> [...] and also that it would too much complicate our development process.

'our' as in the Linux kernel development process? I really don't think it's an 
issue - see above.

or 'our' as in Coccinelle development process? When we brought tools/perf/ into 
the kernel repo all it forced on us were sane Git commits and a predictable, 
(modulo-) 3 months release/stabilization cycle. Both constraints served the 
quality of the perf project very well - but of course your milage may vary.

> One reason for using multiple machines would be to work on multiple 
> architectures.  But Coccinelle is not sensitive to the architecture on 
> which it is run, so perhaps you do't need to have it installed everywhere.

I think the point Pekka tried to make is to have it integrated into the kbuild 
mechanism as well at a certain point. That way it's very easy to use it and we 
maintainers could require frequent patch submitters to use those tools to check 
the quality of their patches. Right now i cannot require that, as it's not part 
of the kernel repo. Requiring a checkpatch.pl check is much easier, as it's 
available to everyone who is writing kernel patches.

'The power of the default' is a very strong force.

Also, IIRC Thomas also sometimes uses Coccinelle to generate *patches*, so 
having it in the kernel would also help that kind of usage.

> > File "/home/penberg/src/linux/scripts/coccinelle/api/memdup_user.cocci",
> > line 32, column 5,  charpos = 747
> >     around = '<+...', whole content = -    <+... when != goto l2;
> > Fatal error: exception Lexer_cocci.Lexical("invalid in a nonempty
> > context: <+...")
> > make[1]: *** [mm/slub.o] Error 1
> > make: *** [mm/slub.o] Error 2
> > 
> > penberg@jaguar:~/src/linux$ dpkg -l|grep coccinelle
> > ii  coccinelle                                      0.2.2.deb-2
> >                                         semantic patching tool for C
> > 
> > [ I'm on Ubuntu 10.10. ]
> 
> Indeed that one seems to be quite out of date.  You can get the most 
> recent version here: https://launchpad.net/~npalix/+archive/coccinelle

With tools/coccinelle/ you would never run into such problems of distributing 
the latest stable version to your fellow kernel developers: it would always be 
available in tools/coccinelle/.

Integration, synergy, availability, distribution and half a dozen other 
buzzwords come to mind as to why it's a good idea to have kernel-focused
tools hosted in the kernel repo :-)

IMO it's an option to consider.

Thanks,

	Ingo
--
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/