Re: [Qemu-devel] [PATCH 2/2] Adding BAR0 for e500 PCI controller

["Andreas Färber" <afaerber@suse.de>]

Am 08.10.2012 10:50, schrieb Alexander Graf:
> 
> On 08.10.2012, at 10:23, Bhushan Bharat-R65777 wrote:
>>>> @@ -307,6 +313,16 @@ static const VMStateDescription
>>>> vmstate_ppce500_pci = {
>>>>
>>>> #include "exec-memory.h"
>>>>
>>>> +static int e500_pcihost_bridge_initfn(PCIDevice *d) {
>>>> +    bharat *b = DO_UPCAST(bharat, p, d);
>>>> +
>>>> +    printf("Addr = %llx, size = %llx\n", ((MemoryRegion *)b->bar0)->addr,
>>> (unsigned long long)int128_get64(((Me
>>>> +    pci_register_bar(d, 0, PCI_BASE_ADDRESS_SPACE_MEMORY,
>>>> + (MemoryRegion *)b->bar0);
>>>
>>> That one still has to call its parent initfn, no?
>>
>> I am really sorry, but I did not get. The object says its parent is TYPE_PCI_DEVICE, so which function are you talking about?
> 
> In object oriented programming, every time you overload a class, your constructor should call the overloaded class's constructor. I don't see this happening for other PCI device's init functions though.
> 
> Andreas, shouldn't parent class init be called for pci subclass devices?

.class_init and .instance_init are called iteratively through the
hierarchy, so no parent method needs to be called manually. This is
different for user-coded methods like CPUState::reset. qdev initfns
haven't changed in that respect to date - they are orthogonal to QOM.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg