All of lore.kernel.org
 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, "Michael S. Tsirkin" <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: Sun, 20 Dec 2015 13:21:15 +0200	[thread overview]
Message-ID: <56768F2B.5030104@redhat.com> (raw)
In-Reply-To: <56768766.1040300@cn.fujitsu.com>

On 12/20/2015 12:48 PM, Cao jin wrote:
> Hi,
>
> On 12/20/2015 06:22 PM, Marcel Apfelbaum wrote:
>>
>> Hi,
>>
>> On 12/18/2015 01:03 PM, Cao jin wrote:
>>> Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com>
>>> ---
>>>   hw/pci-bridge/pci_expander_bridge.c | 24 ++++++++++++++----------
>>>   1 file changed, 14 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/hw/pci-bridge/pci_expander_bridge.c
>>> b/hw/pci-bridge/pci_expander_bridge.c
>>> index 57f8a37..cc975f6 100644
>>> --- a/hw/pci-bridge/pci_expander_bridge.c
>>> +++ b/hw/pci-bridge/pci_expander_bridge.c
>>> @@ -145,19 +145,19 @@ static const TypeInfo pxb_host_info = {
>>>    * Returns 0 on successs, -1 if i440fx host was not
>>>    * found or the bus number is already in use.
>>>    */
>>> -static int pxb_register_bus(PCIDevice *dev, PCIBus *pxb_bus)
>>> +static int pxb_register_bus(PCIDevice *dev, PCIBus *pxb_bus, Error
>>> **errp)
>>
>> If you add an err parameter, maybe the function should return void.
>>
>
> Ok, will modify it in V2. Actually, both style are fine with me:)
>
>>
>>>   {
>>>       PCIBus *bus = dev->bus;
>>>       int pxb_bus_num = pci_bus_num(pxb_bus);
>>>
>>>       if (bus->parent_dev) {
>>> -        error_report("PXB devices can be attached only to root bus.");
>>> +        error_setg(errp, "PXB devices can be attached only to root
>>> bus.");
>>>           return -1;
>>>       }
>>>
>>>       QLIST_FOREACH(bus, &bus->child, sibling) {
>>>           if (pci_bus_num(bus) == pxb_bus_num) {
>>> -            error_report("Bus %d is already in use.", pxb_bus_num);
>>> +            error_setg(errp, "Bus %d is already in use.", pxb_bus_num);
>>>               return -1;
>>>           }
>>>       }
>>> @@ -193,7 +193,7 @@ static gint pxb_compare(gconstpointer a,
>>> gconstpointer b)
>>>              0;
>>>   }
>>>
>>> -static int pxb_dev_initfn(PCIDevice *dev)
>>> +static void pxb_dev_realize(PCIDevice *dev, Error **errp)
>>>   {
>>>       PXBDev *pxb = PXB_DEV(dev);
>>>       DeviceState *ds, *bds;
>>> @@ -202,8 +202,8 @@ static int pxb_dev_initfn(PCIDevice *dev)
>>>
>>>       if (pxb->numa_node != NUMA_NODE_UNASSIGNED &&
>>>           pxb->numa_node >= nb_numa_nodes) {
>>> -        error_report("Illegal numa node %d.", pxb->numa_node);
>>> -        return -EINVAL;
>>> +        error_setg(errp, "Illegal numa node %d.", pxb->numa_node);
>>> +        return;
>>>       }
>>>
>>>       if (dev->qdev.id && *dev->qdev.id) {
>>> @@ -225,8 +225,8 @@ static int pxb_dev_initfn(PCIDevice *dev)
>>>
>>>       PCI_HOST_BRIDGE(ds)->bus = bus;
>>>
>>> -    if (pxb_register_bus(dev, bus)) {
>>> -        return -EINVAL;
>>> +    if (pxb_register_bus(dev, bus, errp)) {
>>> +        goto err_register_bus;
>>>       }
>>>
>>>       qdev_init_nofail(ds);
>>> @@ -237,7 +237,11 @@ static int pxb_dev_initfn(PCIDevice *dev)
>>>       pci_config_set_class(dev->config, PCI_CLASS_BRIDGE_HOST);
>>>
>>>       pxb_dev_list = g_list_insert_sorted(pxb_dev_list, pxb,
>>> pxb_compare);
>>> -    return 0;
>>> +
>>> +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).

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.

>
>>
>>>   }
>>>
>>>   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 :)

Thanks,
Marcel

>
>>
>> Thanks,
>> Marcel
>>
>>>       k->vendor_id = PCI_VENDOR_ID_REDHAT;
>>>       k->device_id = PCI_DEVICE_ID_REDHAT_PXB;
>>>
>>
>>
>>
>> .
>>
>

  reply	other threads:[~2015-12-20 11:21 UTC|newest]

Thread overview: 43+ 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   ` [Qemu-trivial] " Paolo Bonzini
2015-12-18 17:59     ` [Qemu-devel] " Paolo Bonzini
2016-01-10 18:13     ` [Qemu-trivial] " Michael Tokarev
2016-01-10 18:13       ` [Qemu-devel] " 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 [this message]
2015-12-21  2:59         ` Cao jin
2015-12-21 10:08           ` Marcel Apfelbaum
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   ` [Qemu-trivial] " Paolo Bonzini
2015-12-18 17:59     ` [Qemu-devel] " Paolo Bonzini
2016-01-10 18:12     ` [Qemu-trivial] " Michael Tokarev
2016-01-10 18:12       ` [Qemu-devel] " 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=56768F2B.5030104@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.