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), > Object=@d, 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
