From: "Andreas Färber" <afaerber@suse.de>
To: Igor Mammedov <imammedo@redhat.com>
Cc: pbonzini@redhat.com, Markus Armbruster <armbru@redhat.com>,
Anthony Liguori <anthony@codemonkey.ws>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH RFC 2/2] qmp: New command qom-new
Date: Thu, 24 May 2012 16:01:08 +0200 [thread overview]
Message-ID: <4FBE3F24.9010301@suse.de> (raw)
In-Reply-To: <4FBE3C38.8040401@redhat.com>
Am 24.05.2012 15:48, schrieb Igor Mammedov:
> On 05/24/2012 03:04 PM, Anthony Liguori wrote:
>>
>> I'm not sure how I feel about this. I never intended for a user to be
>> able to create objects that were arbitrary children of other objects.
>>
>> In some ways, I think this is almost too powerful of an interface to
>> expose to users. I like things like device_add() better that only
>> creates objects
>> of TYPE_DEVICE that are always in /peripherial.
>>
>> For block, we'd have a similar interface that always created objects
>> of TYPE_BLOCK_DRIVER and put them in /block.
>
> Will we have a special cases for every incompatible device types that is
> going to be hot-plugged via device_add monitor command?
>
> For CPUs my thoughts were moving in opposite direction, like:
> - make possible to create and initialize CPU as a regular QOM object
> - hack qdev_device_add() to allow not only TYPE_DEVICE to be created there
>
> There are patches out there that make cpu a child of /machine at board
> level.
> But for hot-added objects parent could be specified as a property
> or knowledge about parent hard-coded inside of object itself or
> hard-coded in device_add().
> Which one of them likely to be adopted?
For system emulation I am working towards making the CPU a device so
that we can reuse common device infrastructure:
https://github.com/afaerber/qemu-cpu/commits/qom-cpu-dev
That's independent of what QMP commands we provide to the user though.
If we created a TYPE_X86_CPU with -device, we would not get an APIC
attached currently.
If however we created a container object as suggested by Peter and
others before, then we cannot as easily modify properties of the child
objects (family, vendor, etc. of CPU) via command line. Same issue as
with SoCs (the sh7750 realize discussion).
Andreas
--
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-05-24 14:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-24 11:43 [Qemu-devel] [PATCH RFC 0/2] QMP command qom-new Markus Armbruster
2012-05-24 11:43 ` [Qemu-devel] [PATCH RFC 1/2] qom: Give type_get_by_name() external linkage Markus Armbruster
2012-05-24 11:43 ` [Qemu-devel] [PATCH RFC 2/2] qmp: New command qom-new Markus Armbruster
2012-05-24 11:51 ` Paolo Bonzini
2012-05-24 12:58 ` Anthony Liguori
2012-05-24 13:01 ` Andreas Färber
2012-05-24 13:44 ` Paolo Bonzini
2012-05-24 14:12 ` Anthony Liguori
2012-05-24 13:04 ` Anthony Liguori
2012-05-24 13:48 ` Igor Mammedov
2012-05-24 14:01 ` Andreas Färber [this message]
2012-05-24 14:07 ` Anthony Liguori
2012-05-24 15:33 ` Igor Mammedov
2012-05-24 14:04 ` Anthony Liguori
2012-05-24 14:24 ` Markus Armbruster
2012-05-24 15:15 ` Michael Roth
2012-05-24 12:32 ` [Qemu-devel] [PATCH RFC 0/2] QMP " Andreas Färber
2012-05-24 13:06 ` Anthony Liguori
2012-05-24 13:18 ` Peter Maydell
2012-05-24 14:10 ` Anthony Liguori
2012-05-24 14:23 ` Peter Maydell
2012-05-24 14:35 ` Anthony Liguori
2012-05-24 14:52 ` Peter Maydell
2012-05-24 14:08 ` Markus Armbruster
2012-05-24 14:31 ` Andreas Färber
2012-05-24 14:48 ` Markus Armbruster
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=4FBE3F24.9010301@suse.de \
--to=afaerber@suse.de \
--cc=anthony@codemonkey.ws \
--cc=armbru@redhat.com \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).