qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC ppc-next v3 08/10] mac_nvram: QOM'ify MacIO NVRAM


From: Markus Armbruster
Subject: Re: [Qemu-devel] [RFC ppc-next v3 08/10] mac_nvram: QOM'ify MacIO NVRAM
Date: Mon, 14 Jan 2013 18:30:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

Andreas Färber <address@hidden> writes:

> Am 14.01.2013 13:34, schrieb Markus Armbruster:
>> Andreas Färber <address@hidden> writes:
>> 
>>> It was not qdev'ified before, turn it into a SysBusDevice and
>>> initialize it via static properties.
>>>
>>> Prepare Old World specific MacIO state and embed the NVRAM state there.
>>>
>>> Drop macio_nvram_setup_bar() in favor of sysbus_mmio_map() or
>>> direct use of Memory API.
>> [...]
>>> diff --git a/hw/macio.c b/hw/macio.c
>>> index 0e6fc8d..32f359c 100644
>>> --- a/hw/macio.c
>>> +++ b/hw/macio.c
>> [...]
>>> @@ -85,11 +93,22 @@ static int macio_common_initfn(PCIDevice *d)
>>>  static int macio_oldworld_initfn(PCIDevice *d)
>>>  {
>>>      MacIOState *s = MACIO(d);
>>> +    OldWorldMacIOState *os = OLDWORLD_MACIO(d);
>> 
>> I find aliasing pointers like these mildly confusing, and prefer to
>> avoid aliases.  Matter of taste, I guess.
>
> What would you propose instead? When accessing fields we are not
> supposed to use FOO(x)->bar so I don't see any alternative.
> (This notation was chosen I think because it is compatible with
> C++/ObjC/... when exchanging the cast macro.)

Isn't &os->parent_obj == s ?  s-> then becomes os->parent_obj.

Repeat: matter of taste, use your judgement.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]