Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?

[Avi Kivity]

On 08/17/2012 05:52 AM, liu ping fan wrote:
>>
>> Why?  Usually there's a 1:1 mapping between object and opaque.  Can you
>> show cases where there isn't?
>>
> As mentioned ahead, setup_cmd646_bar(PCIIDEState *d, int bus_num),
> address@hidden, but opaque are
> d->cmd646_bar[bus_num], so that is 1:n mapping. And when I browsing
> the code, this is the main issue prevent us to transfer from void* to
> Object* for memory_region_init_io()

In this case there is a 1:1 relationship between CMD646BAR and IDEBus.
IDEBus is a BusState which is an Object.  So this case can be solved easily.

>>> Above methods, the  process of derive the Object will be hard, we can
>>> not tell opaque is Object or not without something like try&catch
>>
>> Take for example e1000.  It passes E1000State as the opaque, which is a
>> PCIDevice, which is a DeviceState, which is an Object.  So for that
>> device, nothing needs to be done.
>>
> The same example, in setup_cmd646_bar(PCIIDEState *d, int bus_num),  I
> think we can not decide which is the type for @bar.  If using
> object_dynamic_cast(@bar, TYPE_OBJECT) to tell whether it is Object or
> not, it will raise exception.

No, dynamic cast cannot work on an arbitrary void *.

There is only one legitimate case IMO where we don't naturally have an
object to work on - device assignment, where all the BARs are
equivalent.  In that case we can just make the BARs also Objects.
Everything else should work naturally with perhaps a little refactoring.

-- 
error compiling committee.c: too many arguments to function