[lkml]   [2011]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] checkpatch: Test for kmalloc/memset(0) pairs

    * Julia Lawall <> wrote:

    > On Sun, 20 Mar 2011, Pekka Enberg wrote:
    > > Hi Julia,
    > >
    > > On Sun, Mar 20, 2011 at 10:01 AM, Julia Lawall <> wrote:
    > > > Suggestions for how to make it easier to use or the documentation more
    > > > understandable are welcome.
    > >
    > > The benefit of scripts/ 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 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:

    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.



     \ /
      Last update: 2011-03-20 11:57    [W:0.026 / U:6.456 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site