On 12/20/2011 03:23 PM, Jan Kiszka wrote:
On 2011-12-20 20:14, Anthony Liguori wrote:
On 12/20/2011 11:02 AM, Jan Kiszka wrote:
On 2011-12-20 15:07, Anthony Liguori wrote:
On 12/20/2011 07:57 AM, Paolo Bonzini wrote:
On 12/20/2011 02:54 PM, Anthony Liguori wrote:
In QOM parlance Jan implemented this:
abstract class Object
abstract class Device
class APIC: { backend: link<APICBackend> }
abstract class APICBackend
class QEMU_APICBackend
class KVM_APICBackend
I don't fundamentally object to modeling it like this provided that
it's
modeled (and visible) through qdev and not done through a one-off
infrastructure.
There is no superclass of DeviceState, hence doing it through qdev
would mean
introducing a new bus type and so on. This would be a superb example
of a
useless bus that can disappear with QOM, but I don't see why we should
take the
pain to add it in the first place. :)
Right, so let's modeled it for now as inheritance which qdev can cope
with.
Do we have a clear plan now how to sort out the addressing issues in
this model? I mean when registering two devices under different names
that are supposed to be addressable under the same alias once
instantiated. I didn't follow recent qtree naming changes in details
unfortunately, if they already enable this.
I think everyone is in agreement. We'll start with an APICBase type
that's modeled in qdev as a base class.
There will be an APICBaseInfo that will replace APICBackend.
There will be two classes that implement APICBaseInfo, KvmAPIC and
APIC. They will be separate devices.
APICBase will register the vmsd and will use the name "apic" to register
it. You can just set the qdev.vmsd field in the apic_qdev_register()
function to ensure that both use the same implementation.
I'm not talking about migration here, I'm talking about qtree
addressability. That is orthogonal, at least right now.
qtree is not an ABI. The output of info qtree can (and will) change over time.
This does not need to be implemented before merge. I just like to have a
common view on how to address it once it matters (for device inspection).
You can do this all today without any pending patches.
Nope, don't see how.
What is this issue?
There is currently no use case for it (e.g. no device_show -
device_add/del makes no sense for the devices in question), but it
should be addressable in QOM in the future.
I guess I'm a bit confused...
Regards,
Anthony Liguori
Jan
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
