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
