From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <17633.22337.802294.171558@cargo.ozlabs.ibm.com> Date: Tue, 15 Aug 2006 15:10:25 +1000 From: Paul Mackerras To: Jan-Bernd Themann Subject: Re: ehea debug output discussion In-Reply-To: <44E06EDA.6040404@de.ibm.com> References: <44D99F38.8010306@de.ibm.com> <20060811215225.GH479@krispykreme> <44DE03B0.1060607@de.ibm.com> <20060813144400.GJ479@krispykreme> <44E06EDA.6040404@de.ibm.com> Cc: Thomas Klein , Jan-Bernd Themann , roland@topspin.com, netdev , Thomas Klein , linux-ppc , Christoph Raisch , Anton Blanchard , Marcus Eder List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Jan-Bernd Themann writes: > The outcome of some internal discussions was that it is not acceptable for > our enterprise users of this type of driver on this target system to need a > recompile / reload of the driver for error analysis, so we need a mechanism > that allows us to switch on / off debug output at runtime. Therefore, we'd > introduce a stripped down version of EDEB. This is precisely what kprobes is for. There is no need for EDEB-style debug code in the source given that kprobes gives you the ability to add logging in at (almost) arbitrary points at runtime. In fact kprobes is more powerful because you don't have to specify the set of points of interest when the kernel is built--you can do it later, at the time of debugging. Please look into providing a kprobes module and/or a systemtap script for the debugging points you want rather than cluttering up the source code with EDEB statements. Paul.