Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751520AbZFON6t (ORCPT ); Mon, 15 Jun 2009 09:58:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751769AbZFON6l (ORCPT ); Mon, 15 Jun 2009 09:58:41 -0400 Received: from outbound-dub.frontbridge.com ([213.199.154.16]:10049 "EHLO IE1EHSOBE006.bigfish.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751528AbZFON6k (ORCPT ); Mon, 15 Jun 2009 09:58:40 -0400 X-SpamScore: -22 X-BigFish: VPS-22(zz1432R98dR1805Mzz1202hzzz32i6bh17ch43j61h) X-Spam-TCS-SCL: 0:0 X-WSS-ID: 0KLA9HG-02-RKI-01 Date: Mon, 15 Jun 2009 15:57:38 +0200 From: Andreas Herrmann To: Thomas Gleixner CC: Jaswinder Singh Rajput , Ingo Molnar , "H. Peter Anvin" , x86 maintainers , Andrew Morton , Andi Kleen , LKML , Yinghai Lu , Dave Jones , Linus Torvalds , Robert Richter Subject: Re: [RFC][GIT PULL][PATCH 0/10 -tip] cpu_debug patches 20090613 Message-ID: <20090615135738.GA7463@alberich.osrc.amd.com> References: <1244910436.11733.14.camel@ht.satnam> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-09) X-OriginalArrivalTime: 15 Jun 2009 13:58:32.0767 (UTC) FILETIME=[5E8EFCF0:01C9EDC1] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2702 Lines: 71 On Sun, Jun 14, 2009 at 12:27:42AM +0200, Thomas Gleixner wrote: > On Sat, 13 Jun 2009, Jaswinder Singh Rajput wrote: > > > Please let me know how we can improve it and add more features so it > > becomes more useful. I second almost all of Thomas points. (The more I am wondering why cpu_debug was merged at all.) IMHO removing the cpuid, msr etc. stuff is the right thing to do. But hey, I even can provide a "use case" for cpu_debug. Recently I wanted to check some APIC registers. Instead of rebooting the machine with apic=debug I loaded the module, mounted debugfs and looked at the cpu_debug stuff to experience that ... The registers that I was interested in were not provided. So I had to add some code to print some of the regs in the extended APIC register with apic=debug code. When submitting the patch upstream I added the same regs to cpu_debug code. This really good shows another weak point of cpu_debug: If the kernel has already code for debugging output cpu_debug just reinvents the wheel and does not even try to reuse existing code. So in the end cpu_debug wasn't useful for me at all. > Dumping random information out of any context is not helping us to > debug problems. There is no value to look at debug registers, context > registers and tss->regs without the context of the task we look at. > > Can we please stop adding more random features to this? > > This needs to be done the other way round. First we need to remove all > redundant and useless interfaces from cpu_debug and then think > carefully about in which way we want to expose the few really missing > interesting things either by extending existing user space tools or by > providing context aware and debug relevant interfaces in the kernel. IMHO the cpu_debug feature should be renamed to platform_debug and then already existing kernel debug code could be modified such that it can also be called from this new platform_debug facility. This would allow to check certain things not only when booting Linux with certain debug parameters but also on the fly when mounting the debugfs ... The registers that come into my mind that would make some kind of sense to provide with that interface are - APIC stuff - HPET stuff Neither MSR, CPUID, CPU regs nor PCI config space stuff should be added. Other facilities/tools exist for those (e.g. x86info, msr-tools, pciutils or Magic SysRq). ... just my two cents. Regards, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/