Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752200Ab1CTMiq (ORCPT ); Sun, 20 Mar 2011 08:38:46 -0400 Received: from mgw2.diku.dk ([130.225.96.92]:59451 "EHLO mgw2.diku.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752092Ab1CTMin (ORCPT ); Sun, 20 Mar 2011 08:38:43 -0400 Date: Sun, 20 Mar 2011 13:38:37 +0100 (CET) From: Julia Lawall To: Ingo Molnar Cc: Pekka Enberg , =?iso-8859-1?Q?Am=E9rico?= Wang , Steven Rostedt , Jonathan Corbet , LKML , Andy Whitcroft , Dave Jones , Andrew Morton , Nicolas Palix , Thomas Gleixner Subject: Re: [PATCH] checkpatch: Test for kmalloc/memset(0) pairs In-Reply-To: <20110320105412.GA11266@elte.hu> Message-ID: References: <1300416744.16880.904.camel@gandalf.stny.rr.com> <20110317211548.646b04d2@tpl.lwn.net> <1300419170.16880.956.camel@gandalf.stny.rr.com> <20110320105412.GA11266@elte.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1644 Lines: 32 > > [...] 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. Yes, I meant the Coccinelle development process. > > 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. There remains the problem that if it is just the sources that are part of the kernel, the user has to have the ocaml compiler installed. julia -- 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/