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
| ||
|
Date: Mon, 5 May 2008 20:23:21 -0700 From: Arjan van de Ven <arjan@...radead.org> To: Theodore Tso <tytso@....edu> Cc: "Randy.Dunlap" <rdunlap@...otime.net>, Ingo Molnar <mingo@...e.hu>, Adrian Bunk <bunk@...nel.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Sam Ravnborg <sam@...nborg.org>, Alexander Viro <viro@....linux.org.uk>, "H. Peter Anvin" <hpa@...or.com> Subject: Re: [rfc] the kernel workflow & trivial "global -> static" patches (was: Re: [2.6 patch] make sched_feat_{names,open} static) On Mon, 5 May 2008 19:45:15 -0400 Theodore Tso <tytso@....edu> wrote: > On Mon, May 05, 2008 at 02:51:32PM -0700, Arjan van de Ven wrote: > > can we do a "make patchcheck" kernel build target that would > > * run checkpatch on teh patch > > * build the kernel without the patch (in various .configs, probably > > allyesconfig / allmodconfig is enough, but we can figure this out > > later) > > * apply the patch > > * build the kernel in the same configs > > * build a kernel for install that has the 'standard debug options' > > on (lockdep, slabpoison etc) > > then we can > > * compare if new gcc warnings got introduced > > * compare if major stack usage got introduced > > * compare if namespace_check and some of the others introduce new > > issues > > * compare if new sparse warnings got introduced > > and maybe even run a bloat-o-meter to show code growth/shrinkage > > [insert other useful checks here] > > > > if all of that is just one command away, I bet quite a few people > > would use it > > (and the more useful it gets the more people will use it) > > I'm not sure we could do it for every single patch (because of the > time it would take), I don't think build power is an actual problem for things like this, since it tends to distribute really well. -- 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