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.
>
>>
>> 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.
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.
Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
