From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TX7qo-00034P-TS for qemu-devel@nongnu.org; Sat, 10 Nov 2012 04:59:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TX7ql-00018u-Rj for qemu-devel@nongnu.org; Sat, 10 Nov 2012 04:59:42 -0500 Received: from chello084112167138.7.11.vie.surfer.at ([84.112.167.138]:40571 helo=wiesinger.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TX7ql-00018Y-Gp for qemu-devel@nongnu.org; Sat, 10 Nov 2012 04:59:39 -0500 Message-ID: <509E2584.3020901@wiesinger.com> Date: Sat, 10 Nov 2012 10:59:32 +0100 From: Gerhard Wiesinger MIME-Version: 1.0 References: <509CBE3A.4040103@redhat.com> <509E10AD.2030602@wiesinger.com> <509E1695.20705@redhat.com> In-Reply-To: <509E1695.20705@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Paolo Bonzini Cc: "qemu-devel@nongnu.org" 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: 1.) Add additional function calls for each DPRINTF statement? 2.) Add just plain DPRINTF statements? 3.) Or a mixture of both: on function call boundaries use Tracing, in function debug info use DPRINTF? 4.) Refactor code that always function calls are involved? Example: static void traceing_func(int mul) { // Do nothing here } // Just some dummy useless function doing illustration static int addandmultiply(int arg1, int arg2) { int mul = 0; int sum = arg1 + arg2; DPRINTF("....", arg1, arg2); // this one can be handled by tracing infrastructure DPRINTF("....", sum); // this one can't be done with tracing if (sum == 0) { DPRINTF("sum=0"); // this one can't be done with tracing return; } mul = arg1 * arg2; DPRINTF(...., mul); // this one can't be done with tracing (except with a introduced tracing function) traceing_func(mul); // Introduce tracing function, performance penalty return sum + mul; } So how to proceed further? Ciao, Gerhard