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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.1103201336530.28495@ask.diku.dk>
Date:	Sun, 20 Mar 2011 13:38:37 +0100 (CET)
From:	Julia Lawall <julia@...u.dk>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Pekka Enberg <penberg@...nel.org>,
	Américo Wang <xiyou.wangcong@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Jonathan Corbet <corbet@....net>,
	LKML <linux-kernel@...r.kernel.org>,
	Andy Whitcroft <apw@...dowen.org>,
	Dave Jones <davej@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Nicolas Palix <npalix@...u.dk>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] checkpatch: Test for kmalloc/memset(0) pairs

> > [...] 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/