From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1F35B0-0005iO-00
	for qemu-devel@nongnu.org; Sun, 29 Jan 2006 00:32:38 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1F35Aw-0005fF-Jg
	for qemu-devel@nongnu.org; Sun, 29 Jan 2006 00:32:36 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1F35Au-0005eH-WC
	for qemu-devel@nongnu.org; Sun, 29 Jan 2006 00:32:33 -0500
Received: from [66.54.152.27] (helo=jive.SoftHome.net)
	by monty-python.gnu.org with smtp (Exim 4.52) id 1F358z-0000wc-G5
	for qemu-devel@nongnu.org; Sun, 29 Jan 2006 00:30:33 -0500
From: Mulyadi Santosa <a_mulyadi@softhome.net>
Subject: Re: [Qemu-devel] Idea: Qemu as test coverage tool for kernels
Date: Sun, 29 Jan 2006 12:26:33 +0700
References: <BAY104-F59C47E86DB180621BD9EFFF170@phx.gbl>
In-Reply-To: <BAY104-F59C47E86DB180621BD9EFFF170@phx.gbl>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200601291226.33968.a_mulyadi@softhome.net>
Reply-To: a_mulyadi@softhome.net, qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org, Blue Swirl <blueswir1@hotmail.com>

Hi...

On Saturday 28 January 2006 19:26, Blue Swirl wrote:
> Hi,
>
> Qemu's system emulators could be modified to output information about
> the code areas which have been executed by the virtual CPU. The
> output could then be used in standard test coverage tools. The
> benefit would be the ability to get kernel-level coverage data.

Why not just use Oprofile (oprofile.sf.net) or standard "readprofile" 
tool for this?

I am not against your idea, but I just want to avoid reinventing the 
wheel

regards

Mulyadi