From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:36491) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T32Se-0002wY-My for qemu-devel@nongnu.org; Sun, 19 Aug 2012 06:10:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T32Sd-0002Zt-Ip for qemu-devel@nongnu.org; Sun, 19 Aug 2012 06:10:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36632) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T32Sd-0002Zp-9X for qemu-devel@nongnu.org; Sun, 19 Aug 2012 06:10:23 -0400 Message-ID: <5030BB87.6010505@redhat.com> Date: Sun, 19 Aug 2012 13:10:15 +0300 From: Avi Kivity MIME-Version: 1.0 References: <502A2D26.4060702@redhat.com> <502CBC26.9030705@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: liu ping fan Cc: qemu-devel@nongnu.org, Anthony Liguori 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