From: "Andreas Färber" <afaerber@suse.de>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
Riku Voipio <riku.voipio@iki.fi>, Alexander Graf <agraf@suse.de>,
qemu-devel@nongnu.org, Blue Swirl <blauwirbel@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 2/2] cpu: for cpu-user and cpu-softmmu and make cpu-softmmu a child of DeviceState
Date: Sat, 23 Jun 2012 16:00:28 +0200 [thread overview]
Message-ID: <4FE5CBFC.6010902@suse.de> (raw)
In-Reply-To: <1340393807-15224-2-git-send-email-aliguori@us.ibm.com>
Am 22.06.2012 21:36, schrieb Anthony Liguori:
> The line between linux-user and softmmu is not very well defined right now.
> linux-user really don't want to include devices and making CpuState a child of
> DeviceState would require pulling lots of stuff into linux-user.
>
> To solve this, we simply fork cpu-user and cpu-softmmu letting them evolve
> independently.
[snip]
I still don't understand why.
>From your announcement on IRC I thought that you would leave TYPE_CPU as
is and introdruce TYPE_SOFTMMU_CPU / TYPE_USER_CPU as derived
intermediate types. But here you are just replacing my suggested #ifdefs
with code duplication...
The QOM CPUState part 4 series on the list I reminded you of starts
moving more stuff into struct CPUState, which is supposed to be used by
common code, i.e., both softmmu and *-user.
With this patch of yours I'd need to move the fields from central
CPU_COMMON into *two* structs kept in sync, which doesn't feel like an
advantage to me. Apart from fields for include/qemu/cpu.h I was also
planning on placing helper functions into qom/cpu.c, which now would
need to be duplicated, like cpu_common_reset() for the fields added. So
if there's some error it is likely to get fixed in one version but
forgotten in the other one. That would be really bad. If functions do
mostly the same thing they should be compiled from the same source -
basics of Product Line Engineering. If there's functions that only apply
to one of them then I'm fine placing them in a cpu-softmmu or cpu-user
file respectively. But this patch 2/2 just seems to make more work
without real gains to avoid #ifdefs - we'll get some anyway due to w32
and unrolling those into even more file copies sounds even worse.
Apart from tcg/, which you keep iterating, linux-user also reuses most
of target-*/ (except for supervisor- and hypervisor-level instructions)
as well as core CPU execution infrastructure, which I'm trying to
streamline through CPUState compiled only twice rather than per each
*-softmmu and *-*-user.
So IMO the key point is that we don't want them to evolve independently.
We want to code efficiently and to build QEMU efficiently.
Regards,
Andreas
For reference my previous suggestion for CPUState-as-a-DeviceState was:
diff --git a/include/qemu/cpu.h b/include/qemu/cpu.h
index 78b65b3..a4d84a5 100644
--- a/include/qemu/cpu.h
+++ b/include/qemu/cpu.h
@@ -21,6 +21,9 @@
#define QEMU_CPU_H
#include "qemu/object.h"
+#ifndef CONFIG_USER_ONLY
+#include "hw/qdev.h"
+#endif
/**
* SECTION:cpu
@@ -45,7 +48,11 @@ typedef struct CPUState CPUState;
*/
typedef struct CPUClass {
/*< private >*/
+#ifdef CONFIG_USER_ONLY
ObjectClass parent_class;
+#else
+ DeviceClass parent_class;
+#endif
/*< public >*/
void (*reset)(CPUState *cpu);
diff --git a/qom/cpu.c b/qom/cpu.c
index 5b36046..17b796f 100644
--- a/qom/cpu.c
+++ b/qom/cpu.c
@@ -36,14 +36,26 @@ static void cpu_common_reset(CPUState *cpu)
static void cpu_class_init(ObjectClass *klass, void *data)
{
+#ifndef CONFIG_USER_ONLY
+ DeviceClass *dc = DEVICE_CLASS(klass);
+#endif
CPUClass *k = CPU_CLASS(klass);
+#ifndef CONFIG_USER_ONLY
+ /* Overwrite this in subclasses for which hotplug is supported. */
+ dc->no_user = 1;
+#endif
+
k->reset = cpu_common_reset;
}
static TypeInfo cpu_type_info = {
.name = TYPE_CPU,
+#ifdef CONFIG_USER_ONLY
.parent = TYPE_OBJECT,
+#else
+ .parent = TYPE_DEVICE,
+#endif
.instance_size = sizeof(CPUState),
.abstract = true,
.class_size = sizeof(CPUClass),
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2012-06-23 14:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-22 19:36 [Qemu-devel] [PATCH 1/2] qdev: split up header so it can be used in cpu.h Anthony Liguori
2012-06-22 19:36 ` [Qemu-devel] [PATCH 2/2] cpu: for cpu-user and cpu-softmmu and make cpu-softmmu a child of DeviceState Anthony Liguori
2012-06-23 14:00 ` Andreas Färber [this message]
2012-06-24 7:07 ` Blue Swirl
-- strict thread matches above, loose matches on Subject: below --
2012-08-10 17:00 [Qemu-devel] [PATCH 0/2] cpu: make " Anthony Liguori
2012-08-10 17:00 ` [Qemu-devel] [PATCH 2/2] cpu: for cpu-user and cpu-softmmu and make cpu-softmmu " Anthony Liguori
2012-08-10 17:09 ` Eduardo Habkost
2012-08-10 18:28 ` Anthony Liguori
2012-08-15 15:41 ` Andreas Färber
2012-08-15 16:29 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FE5CBFC.6010902@suse.de \
--to=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=aliguori@us.ibm.com \
--cc=blauwirbel@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).