qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Zhi Yong Wu <zwu.kernel@gmail.com>
Cc: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org, stefanha@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [RFC 1/9] hostdev: introduce the infrastructure for host device model
Date: Wed, 28 Mar 2012 08:41:51 +0200	[thread overview]
Message-ID: <4F72B2AF.8050704@redhat.com> (raw)
In-Reply-To: <CAEH94LgNL0ir8DurxYhCftQbh8SLrJ-o8u0H-ZYEdKcaY3uYbw@mail.gmail.com>

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.

>> 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.

>>>>> 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?

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.

Paolo

  reply	other threads:[~2012-03-28  6:42 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-26  5:40 [Qemu-devel] [RFC 0/9] QOM: qomify -netdev zwu.kernel
2012-03-26  5:40 ` [Qemu-devel] [RFC 1/9] hostdev: introduce the infrastructure for host device model zwu.kernel
2012-03-26  5:54   ` Zhi Yong Wu
2012-03-27  8:23   ` Paolo Bonzini
2012-03-27  9:06     ` Zhi Yong Wu
2012-03-27 10:15       ` Paolo Bonzini
2012-03-27 11:59         ` Zhi Yong Wu
2012-03-27 13:58           ` Paolo Bonzini
2012-03-27 14:18             ` Zhi Yong Wu
2012-03-27 14:50               ` Paolo Bonzini
2012-03-27 21:21                 ` Zhi Yong Wu
2012-03-28  6:41                   ` Paolo Bonzini [this message]
2012-03-28  7:50                     ` Zhi Yong Wu
2012-03-28  7:53                     ` Zhi Yong Wu
2012-03-28  8:02                       ` Paolo Bonzini
2012-03-28  8:05                         ` 陳韋任
2012-03-28  8:25                           ` Zhi Yong Wu
2012-03-28  8:29                             ` 陳韋任
2012-03-26  5:40 ` [Qemu-devel] [PATCH] net: qomify -netdev zwu.kernel
2012-03-26  5:40 ` zwu.kernel
2012-03-26  5:44   ` Zhi Yong Wu
2012-03-26  5:40 ` [Qemu-devel] [RFC 2/9] net: introduce one net host device class zwu.kernel
2012-03-27  8:30   ` Paolo Bonzini
2012-03-27  9:13     ` Zhi Yong Wu
2012-03-26  5:40 ` [Qemu-devel] [RFC 3/9] net: adjust net common part for qomify -netdev zwu.kernel
2012-03-26  5:40 ` [Qemu-devel] [RFC 4/9] net: adjust nic init API zwu.kernel
2012-03-26  5:40 ` [Qemu-devel] [RFC 5/9] net: adjust dump " zwu.kernel
2012-03-26  5:40 ` [Qemu-devel] [RFC 6/9] net: qomify -netdev user zwu.kernel
2012-03-26  5:40 ` [Qemu-devel] [RFC 7/9] net: qomify -netdev socket zwu.kernel
2012-03-26  5:40 ` [Qemu-devel] [RFC 8/9] net: qomify -netdev vde zwu.kernel
2012-03-26  5:40 ` [Qemu-devel] [RFC 9/9] net: qomify -netdev tap & -netdev bridge zwu.kernel
2012-03-26 11:54 ` [Qemu-devel] [RFC 0/9] QOM: qomify -netdev Stefan Hajnoczi
2012-03-26 14:20   ` Zhi Yong Wu
2012-03-27  8:19     ` Paolo Bonzini
2012-03-27  9:03       ` Zhi Yong Wu
2012-03-26 14:39   ` Andreas Färber
2012-03-26 14:57     ` Stefan Hajnoczi
2012-03-26 15:01     ` Zhi Yong Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F72B2AF.8050704@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@linux.vnet.ibm.com \
    --cc=wuzhy@linux.vnet.ibm.com \
    --cc=zwu.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).