qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC 1/9] hostdev: introduce the infrastructure for hos


From: Zhi Yong Wu
Subject: Re: [Qemu-devel] [RFC 1/9] hostdev: introduce the infrastructure for host device model
Date: Wed, 28 Mar 2012 05:21:03 +0800

On Tue, Mar 27, 2012 at 10:50 PM, Paolo Bonzini <address@hidden> wrote:
> Il 27/03/2012 16:18, Zhi Yong Wu ha scritto:
>> On Tue, Mar 27, 2012 at 9:58 PM, Paolo Bonzini <address@hidden> wrote:
>>> Il 27/03/2012 13:59, Zhi Yong Wu ha scritto:
>>>> On Tue, Mar 27, 2012 at 6:15 PM, Paolo Bonzini <address@hidden> wrote:
>>>>> Il 27/03/2012 11:06, Zhi Yong Wu ha scritto:
>>>>>>>>>> +#define DEFINE_HOSTDEV_PROP_PEER(_n, _s, _f)             \
>>>>>>>>>> +    DEFINE_HOSTDEV_PROP(_n, _s, _f, hostdev_prop_netdev, 
>>>>>>>>>> NetClientState*)
>>>>>>>>
>>>>>>>> This should be simply a link<NetDev> property.
>>>>>> IMHO, i don't fully understand what link<NetDev> mean. What is the
>>>>>> difference between it and Child<NetDev>. Can you elaborate this?
>>>>>
>>>>> link<NetDev> is a pointer to another object.  child<NetDev> means that
>>>> Where are link<NetDev> used?
>>>
>>> The peer property needs to be one.
>> sorry, i don't get what it means.
>
> Links are pointers.  As you convert host devices to QOM, pointer
> properties such as drive or chardev need to become links.  Peer is
> another pointer property that needs to become a link.
It makes sense to me, thanks.
>
>>>> what is relationship between the two objects?
>>>
>>> A has a pointer to B.
>>
>> I knew this, but can you say one example in QEMU device model? I
>> checked QEMU code, and found that those link functions in object.c are
>> not currently used. right?
>
> Yes, that's correct.  Everything that uses PROP_PTR needs to become a
But i didn't see that that stuff which uses PROP_PTR become a link in
current QEMU code.
For example:
static Property apic_properties_common[] = {
  ......
    DEFINE_PROP_PTR("cpu_env", APICCommonState, cpu_env),
  .....
    DEFINE_PROP_END_OF_LIST(),
};

It define one PROP_PTR cpu_env, but i didn't see stuff which made it
become one link. Did i miss anything?

> link.  We cannot do that yet because devices do not yet have a canonical
> path.
Cannonical path means that it is one absolute path or partial path?
>
>>>> Moreover, -device has exposed network card info.
>>>
>>> ... this is extremely confused.  Each NIC device has a NIC-type
>>> NetClientState.  If NetClientState is converted to QOM, all of its
>> The original idea about -netdev QOM is to convert NetClientState to
>> QOM, but now this idea seems to be changed.
>
> I cannot parse this at all.  You have not converted all of
> NetClientState to QOM, have you?
No. I am not sure if we need to convert all and we need to know what
the benefit is.
>
>>>> We hope that -netdev options info can be configurated or changed
>>>> purely via QOM, not command line.
>>>
>>> Yes, but does it buy anything or it is just a nice exercise?
>>
>> buy anything? sorry, i don't understand this.
>
> What's the advantage?  Converting chardev would give hotplug.  What can
> we do with a QOMified netdev that we cannot do now?
It can be configurated or changed purely via QOM, this is one of the
advantages by itself. And I think that it should also give hotplug.
>
> Paolo



-- 
Regards,

Zhi Yong Wu



reply via email to

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