qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH RFC 2/2] qmp: New command qom-new


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH RFC 2/2] qmp: New command qom-new
Date: Thu, 24 May 2012 09:07:12 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 05/24/2012 09:01 AM, Andreas Färber wrote:
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:

Ah, perfect, I guess great minds think alike :-)

Regards,

Anthony Liguori



reply via email to

[Prev in Thread] Current Thread [Next in Thread]