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

[Zhi Yong Wu]

On Wed, Mar 28, 2012 at 2:41 PM, Paolo Bonzini <address@hidden> wrote:
> Il 27/03/2012 23:21, Zhi Yong Wu ha scritto:
>>> 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.
>
> Yes, that's why I wrote "needs to become".  In order to use links, you
> need two things:
>
> * the target needs to have a canonical path (more on this below);
>
> * the target needs to be QOMified.
>
> Most PTR properties are pointers to devices, but devices so far don't
> always have a canonical path so the conversion could not happen.  Others
> are to CPUs, which are not yet QOMified.
nice, got it. link is next step for PROP_PTR, thanks
>
>>> 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?
>
> Canonical path means it consists exclusively of child<> properties.
> Unlike the links, which form a graph, children form a tree so it's easy
> to define a canonical naming of all objects.
>
>>>>>> 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 do.  You just cannot convert the same object half to QOM and half
> not.  It leads to insanity.
OK, i will convert all.
>
>>>>>> 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.
>
> Sure, but what does it do better than netdev_add?
If -netdev QOM is supported, libvirt can use non-root account to get
some service from QEMU. this will enforce security, right?
>
> Note that the same holds for devices.  Anthony converted them as the
> proof that QOM could deal with them, and that conversions could be done
> in small steps.  But strictly speaking it was not necessary to convert
> them to QOM; so far, conversion brought no substantial improvement.
>
>> And I think that it should also give hotplug.
>
> Hotplug of -netdev is already supported.
ah? IHMO, i have limited knowledge about QOM, and don't know why you
said that chardev QOM can provide hotplug, how to play with it?

>
> Paolo



-- 
Regards,

Zhi Yong Wu