From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757598AbZGCQmn (ORCPT ); Fri, 3 Jul 2009 12:42:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756409AbZGCQmf (ORCPT ); Fri, 3 Jul 2009 12:42:35 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:41817 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756369AbZGCQmf (ORCPT ); Fri, 3 Jul 2009 12:42:35 -0400 Date: Fri, 3 Jul 2009 18:42:25 +0200 From: Ingo Molnar To: Alan Cox Cc: linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: [PATCH] vt: add an event interface Message-ID: <20090703164225.GA21447@elte.hu> References: <20090703095432.GC21141@elte.hu> <20090703110620.64fd1283@lxorguk.ukuu.org.uk> <20090703102234.GA32128@elte.hu> <20090703114431.37abd528@lxorguk.ukuu.org.uk> <20090703131727.GA3207@elte.hu> <20090703143746.0379b2ee@lxorguk.ukuu.org.uk> <20090703144754.GA13246@elte.hu> <20090703160230.093e422c@lxorguk.ukuu.org.uk> <20090703155809.GA20121@elte.hu> <20090703172651.619162fd@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090703172651.619162fd@lxorguk.ukuu.org.uk> User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.5 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Alan Cox wrote: > A good example of what happens if you don't is > > scripts/checkpatch.pl --file arch/x86/kernel/cpu/mtrr/*c > > where the core part of the code isn't changed very much even > though the interfaces completely get reworked. Thus it never gets > cleaned up and reviewed as a whole. The code works, will probably > work for years but never gets looked at as a whole and tidied. I think even the MTRR code (which is indeed one of the few x86 places still not fully cleaned up) supports my arguments. Look at the averages: errors lines of code errors/KLOC arch/x86/kernel/cpu/mtrr/amd.c 2 120 16.6 arch/x86/kernel/cpu/mtrr/centaur.c 8 225 35.5 arch/x86/kernel/cpu/mtrr/cleanup.c 0 1102 0 arch/x86/kernel/cpu/mtrr/cyrix.c 10 275 36.3 arch/x86/kernel/cpu/mtrr/generic.c 16 730 21.9 arch/x86/kernel/cpu/mtrr/if.c 11 428 25.7 arch/x86/kernel/cpu/mtrr/main.c 50 751 66.5 arch/x86/kernel/cpu/mtrr/state.c 0 83 0 The arch/x86/kernel/cpu/mtrr/cleanup.c file is a new bit and relatively clean. Ingo