From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41577) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYFb1-0003ms-WA for qemu-devel@nongnu.org; Tue, 13 Nov 2012 07:28:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TYFay-00026v-Tb for qemu-devel@nongnu.org; Tue, 13 Nov 2012 07:28:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:32518) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TYFay-00026p-MB for qemu-devel@nongnu.org; Tue, 13 Nov 2012 07:28:00 -0500 Message-ID: <50A23CCD.6020504@redhat.com> Date: Tue, 13 Nov 2012 13:27:57 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <509CBE3A.4040103@redhat.com> <509E10AD.2030602@wiesinger.com> <509E1695.20705@redhat.com> <509E2584.3020901@wiesinger.com> In-Reply-To: <509E2584.3020901@wiesinger.com> Content-Type: text/plain; charset=ISO-8859-1 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: Gerhard Wiesinger Cc: Paolo Bonzini , "qemu-devel@nongnu.org" 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: > 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 What's the problem? It would usually turn into something like trace_addandmultiply_sum(sum); where trace_addandmultiply_sum() is a generated static inline function in trace.h, which is empty and has zero overhead with disabled tracing. Kevin