From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759040AbYEEXqR (ORCPT ); Mon, 5 May 2008 19:46:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752662AbYEEXqE (ORCPT ); Mon, 5 May 2008 19:46:04 -0400 Received: from www.church-of-our-saviour.ORG ([69.25.196.31]:34797 "EHLO thunker.thunk.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752484AbYEEXqC (ORCPT ); Mon, 5 May 2008 19:46:02 -0400 Date: Mon, 5 May 2008 19:45:15 -0400 From: Theodore Tso To: Arjan van de Ven Cc: "Randy.Dunlap" , Ingo Molnar , Adrian Bunk , Peter Zijlstra , linux-kernel@vger.kernel.org, Andrew Morton , Linus Torvalds , Sam Ravnborg , Alexander Viro , "H. Peter Anvin" Subject: Re: [rfc] the kernel workflow & trivial "global -> static" patches (was: Re: [2.6 patch] make sched_feat_{names,open} static) Message-ID: <20080505234515.GB8357@mit.edu> Mail-Followup-To: Theodore Tso , Arjan van de Ven , "Randy.Dunlap" , Ingo Molnar , Adrian Bunk , Peter Zijlstra , linux-kernel@vger.kernel.org, Andrew Morton , Linus Torvalds , Sam Ravnborg , Alexander Viro , "H. Peter Anvin" References: <20080505182942.GA17139@cs181133002.pp.htv.fi> <20080505201906.GA900@elte.hu> <20080505145132.58df7e70@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080505145132.58df7e70@infradead.org> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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), but how about automating it so that for every single tree which is getting pushed to linux-next, we have a build tree which automatically builds "origin..next" (i.e., the set of commits that are being proposed for pushing into mainline), comparing whether the current set of changes being proposed for pushing to mainline, for each tree. Ideally the maintainer would do this himself before nominating the set of patches to linux-next, but if not, if someone were interested in doing this work automatically, and then sending the results to the developer and cc'ed to LKML as a service, it would probably serve a useful "gentle nudge" towards doing the right thing. :-) - Ted