From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:47055)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <vilanova@ac.upc.edu>) id 1R4dON-0005Py-5c
	for qemu-devel@nongnu.org; Fri, 16 Sep 2011 14:44:04 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <vilanova@ac.upc.edu>) id 1R4dOL-00009G-KM
	for qemu-devel@nongnu.org; Fri, 16 Sep 2011 14:44:02 -0400
Received: from gw.ac.upc.edu ([147.83.30.3]:45260)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <vilanova@ac.upc.edu>) id 1R4dOL-00008O-Cm
	for qemu-devel@nongnu.org; Fri, 16 Sep 2011 14:44:01 -0400
From: =?utf-8?Q?Llu=C3=ADs_Vilanova?= <vilanova@ac.upc.edu>
References: <20110916170124.16838.70890.stgit@ginnungagap.bsc.es>
	<4E738263.3090307@siemens.com>
Date: Fri, 16 Sep 2011 20:43:52 +0200
In-Reply-To: <4E738263.3090307@siemens.com> (Jan Kiszka's message of "Fri, 16
	Sep 2011 19:07:47 +0200")
Message-ID: <87aaa45nvb.fsf@ginnungagap.bsc.es>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH 1/3] Add "qemu_reset_vcpu"
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: qemu-devel@nongnu.org

Jan Kiszka writes:

> On 2011-09-16 19:01, Llu=C3=ADs Vilanova wrote:
>> Mimics the already-existing "qemu_init_vcpu".

> Bad name as it implies something important happens inside. Call it
> trace_reset_vcpu because that is what it will do.

I just thought it is much cleaner to call a generic "qemu_reset_vcpu"
function that _might_ do something related to resetting the vCPU state,
regardless of whether there is a tracing event for it or not.

Otherwise if someone wants to add some generic vCPU-resetting code in
the future, the tracing function might end up in the target-specific
code instead of the generic qemu code.

If you still think this is a bad idea I'll resend a patch with both
events renamed into trace_vcpu_init/trace_vcpu_reset.


Thanks,
    Lluis

--=20
 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Tollbooth