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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ