qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Apfelbaum <marcel@redhat.com>
To: Cao jin <caoj.fnst@cn.fujitsu.com>, qemu-devel@nongnu.org
Cc: ehabkost@redhat.com, mst@redhat.com,
	"Markus Armbruster" <armbru@redhat.com>,
	pbonzini@redhat.com, leon.alrae@imgtec.com,
	"Andreas Färber" <afaerber@suse.de>,
	aurelien@aurel32.net, rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH 3/5] PXB: convert to realize()
Date: Mon, 21 Dec 2015 12:08:08 +0200	[thread overview]
Message-ID: <5677CF88.7010001@redhat.com> (raw)
In-Reply-To: <56776B07.7000102@cn.fujitsu.com>

On 12/21/2015 04:59 AM, Cao jin wrote:
>
>
> On 12/20/2015 07:21 PM, Marcel Apfelbaum wrote:
>> On 12/20/2015 12:48 PM, Cao jin wrote:
>>> Hi,
>>>
>>> On 12/20/2015 06:22 PM, Marcel Apfelbaum wrote:
> [...]
>>>>> +
>>>>> +err_register_bus:
>>>>> +    object_unref(OBJECT(ds));
>>>>> +    object_unref(OBJECT(bds));
>>>>> +    object_unref(OBJECT(bus));
>>>>
>>>>
>>>> The order should be in the reverse order of creation:
>>>>      bds, bus, ds
>>>>
>>>
>>> Ok, I can do that. But it seems the order here doesn`t matter? Is
>>> there dependency among these three?
>>
>> Yes, there is a dependency:
>> At first the pxb host (ds) is created, then the bus (bus) is created as
>> host's child (see pci_bus_new)
>> and in the end a pci bridge (bds) is attached to the bus (see qdev_create).
>>
>
> Yup...thanks for reminding, I did read the code trying to find the parent relationship...but seem I didn`t read it thoroughly:-[
>
>> By the way, indeed you should call object_unparent at least for the
>> pxb_host(ds), but you may want to
>> check the others parent relationship as well.
>>
>
> yes, but I think you are saying: object_unparent(bus), right? the relationship seems is:
>    pxb host-->(child property)bus-->(link property)bds
>
> Another question: because some of this series is CCed to qemu-trivial(which means: reviewed-by?) by other maintainer, so next time, do I need to send the whole series with "v2", or the rest?

Hi,

Since the patches are not related, the ones cc-ed to qemu-trivial will be taken by the maintainer of trivial patches,
for the rest you should prepare a V2 to be reviewed by the corresponding sub-tree maintainer.

CC to qemu-trivial does not mean "reviewed-by", it just implies the
patch is simple enough to go through the trivial tree and does not need to go through the sub-tree maintainer.

Thanks,
Marcel

>
>>>
>>>>
>>>>>   }
>>>>>
>>>>>   static void pxb_dev_exitfn(PCIDevice *pci_dev)
>>>>> @@ -259,7 +263,7 @@ static void pxb_dev_class_init(ObjectClass *klass,
>>>>> void *data)
>>>>>       DeviceClass *dc = DEVICE_CLASS(klass);
>>>>>       PCIDeviceClass *k = PCI_DEVICE_CLASS(klass);
>>>>>
>>>>> -    k->init = pxb_dev_initfn;
>>>>> +    k->realize = pxb_dev_realize;
>>>>>       k->exit = pxb_dev_exitfn;
>>>>
>>>> If init is converted to realize, maybe the exit should be converted to
>>>> unrealize?
>>>>
>>>
>>> Yup, I agree with you from the point that the names should be antonym.
>>> But it seems there is no PCIDeviceClass.unrealize:(
>>
>> You are right. The pci_qdev_unrealize ultimately calls exit. But the
>> same goes for init, pci_qdev_realize calls for pc->realize.
>> This is the reason I chose to use init/exit instead of the strange
>> realize/exit.
>>
>> But since the intention is to get rid of init, I am not against it.
>>
>>>
>>> And I am also not aware why there is no comment for .exit while there
>>> is for .init. It is appreciated if somebody could tell me the history
>>> O:-)
>>
>> I'll add Markus, Andreas and Michael (the PCI maintainer), maybe they
>> have a better insight to this.
>>
>> On the other hand you should continue with the patch and leave the
>> "unrealize" until we'll know more :)
>
> Got it;)
>
>>
>> Thanks,
>> Marcel
>>
>>>
>>>>
>>>> Thanks,
>>>> Marcel
>>>>
>>>>>       k->vendor_id = PCI_VENDOR_ID_REDHAT;
>>>>>       k->device_id = PCI_DEVICE_ID_REDHAT_PXB;
>>>>>
>>>>
>>>>
>>>>
>>>> .
>>>>
>>>
>>
>>
>>
>> .
>>
>

  reply	other threads:[~2015-12-21 10:08 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-18 11:03 [Qemu-devel] [PATCH 0/5] Convert to realize() Cao jin
2015-12-18 11:03 ` [Qemu-devel] [PATCH 1/5] SH PCI Host: convert " Cao jin
2015-12-18 17:59   ` Paolo Bonzini
2016-01-10 18:13     ` Michael Tokarev
2015-12-18 11:03 ` [Qemu-devel] [PATCH 2/5] igd-passthrough-i440FX: " Cao jin
2015-12-18 18:37   ` Eduardo Habkost
2015-12-18 21:18     ` Markus Armbruster
2015-12-20 11:59       ` Cao jin
2016-01-11 14:32         ` Markus Armbruster
2016-01-12  2:24           ` Cao jin
2015-12-20 11:56     ` Cao jin
2015-12-18 11:03 ` [Qemu-devel] [PATCH 3/5] PXB: " Cao jin
2015-12-18 18:01   ` Paolo Bonzini
2015-12-20 11:38     ` Cao jin
2015-12-21 10:39       ` Cao jin
2015-12-21 15:49       ` Paolo Bonzini
2015-12-22  3:58         ` Cao jin
2015-12-22  7:34           ` Marcel Apfelbaum
2015-12-22  9:16             ` Cao jin
2015-12-22  9:35               ` Marcel Apfelbaum
2015-12-22  9:52                 ` Cao jin
2015-12-22 11:40                 ` Cao jin
2015-12-20 10:22   ` Marcel Apfelbaum
2015-12-20 10:48     ` Cao jin
2015-12-20 11:21       ` Marcel Apfelbaum
2015-12-21  2:59         ` Cao jin
2015-12-21 10:08           ` Marcel Apfelbaum [this message]
2015-12-21 10:19             ` Cao jin
2015-12-18 11:03 ` [Qemu-devel] [PATCH 4/5] gt64120: " Cao jin
2015-12-18 17:59   ` Paolo Bonzini
2016-01-10 18:12     ` Michael Tokarev
2015-12-18 11:03 ` [Qemu-devel] [PATCH 5/5] xen-pvdevice: " Cao jin
2015-12-18 18:00   ` Paolo Bonzini
2015-12-21  5:52     ` Cao jin
2015-12-21 15:00       ` Stefano Stabellini
2015-12-21 15:15   ` Stefano Stabellini
2015-12-22  1:24     ` Cao jin
2015-12-22  2:40       ` Cao jin
2015-12-18 11:08 ` [Qemu-devel] [PATCH 0/5] Convert " Cao jin

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=5677CF88.7010001@redhat.com \
    --to=marcel@redhat.com \
    --cc=afaerber@suse.de \
    --cc=armbru@redhat.com \
    --cc=aurelien@aurel32.net \
    --cc=caoj.fnst@cn.fujitsu.com \
    --cc=ehabkost@redhat.com \
    --cc=leon.alrae@imgtec.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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).