From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45831) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYGfc-0002gu-M6 for qemu-devel@nongnu.org; Tue, 13 Nov 2012 08:36:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYGfZ-0007Zf-KD for qemu-devel@nongnu.org; Tue, 13 Nov 2012 08:36:52 -0500 Received: from mail-vc0-f173.google.com ([209.85.220.173]:41804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYGfZ-0007ZR-Fw for qemu-devel@nongnu.org; Tue, 13 Nov 2012 08:36:49 -0500 Received: by mail-vc0-f173.google.com with SMTP id fl15so7172436vcb.4 for ; Tue, 13 Nov 2012 05:36:48 -0800 (PST) Date: Tue, 13 Nov 2012 14:36:43 +0100 From: Stefan Hajnoczi Message-ID: <20121113133643.GA15563@stefanha-thinkpad.muc.redhat.com> References: <509CBE3A.4040103@redhat.com> <509E10AD.2030602@wiesinger.com> <509E1695.20705@redhat.com> <509E2584.3020901@wiesinger.com> <50A23CCD.6020504@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50A23CCD.6020504@redhat.com> Subject: Re: [Qemu-devel] [PATCH] block.c, block/vmdk.c: Fixed major bug in VMDK WRITE and READ handling - FIXES DATA CORRUPTION List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Gerhard Wiesinger , Paolo Bonzini , "qemu-devel@nongnu.org" On Tue, Nov 13, 2012 at 01:27:57PM +0100, Kevin Wolf wrote: > Am 10.11.2012 10:59, schrieb Gerhard Wiesinger: > > On 10.11.2012 09:55, Paolo Bonzini wrote: > >> Il 10/11/2012 09:30, Gerhard Wiesinger ha scritto: > >>>>> 2.) Added debug code to block.c and to block/vmdk.c to verify > >>>>> correctness > >>>> Same here. Also, please use the tracing infrastructure---a lot of the > >>>> debug > >>>> messages you're adding, though not all, are in fact already available > >>>> (not > >>>> saying the others aren't useful!) > >>> Any chance that the patch with debug code only (after some cleaning) > >>> would be accepted (other modules do debug logging, too)? > >>> I don't like to do useless work. > >>> Tracing infrastructure is quite limited to function calls only (as far > >>> as I saw). > >> No, tracing infrastructure uses function calls for tracing (messages go > >> into trace-events) but you can apply it to everything you want. Use the > >> stderr backend to debug it. > > > > Tracing is a good thing for normal behavior but the major limitation is > > that a function call must be involved. But for deep debugging one needs > > a lot of more messages than function calls are available. > > > > Of course every DPRINTF line could be made in a function call but IHMO > > this introduces unnecessary overhead in performance. > > > > So how to proceed further, some options: QEMU tracing has a solution for this, use the *_ENABLED macro to determine at compile-time whether tracing code should be compiled in or not: if (TRACE_MY_EXPENSIVE_THING_ENABLED) { const char *pi = calculate_pi_to_10000000000_decimal_places(); trace_my_expensive_thing(pi); } If the trace event is marked with "disable" in trace-events, then TRACE_MY_EXPENSIVE_THING_ENABLED will be 0 and the compiler will drop the dead code. This way you can put expensive debug-only tracing into QEMU without affecting production builds - you do lose the advantage of being able to toggle "disabled" trace events at runtime, but it still beats DPRINTF(). Stefan