From: Avi Kivity <avi@redhat.com>
To: liu ping fan <qemulist@gmail.com>
Cc: qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] memory: could we add extra input param for memory_region_init_io()?
Date: Sun, 19 Aug 2012 13:10:15 +0300 [thread overview]
Message-ID: <5030BB87.6010505@redhat.com> (raw)
In-Reply-To: <CAJnKYQkdufxHaz5=2bTjAd6SvDr5dvnmVeN-UeKjJowoWCOJhw@mail.gmail.com>
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
prev parent reply other threads:[~2012-08-19 10:10 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-14 8:30 [Qemu-devel] memory: could we add extra input param for memory_region_init_io()? liu ping fan
2012-08-14 10:49 ` Avi Kivity
2012-08-16 3:22 ` liu ping fan
2012-08-16 9:23 ` Avi Kivity
2012-08-17 2:52 ` liu ping fan
2012-08-17 7:41 ` liu ping fan
2012-08-19 10:12 ` Avi Kivity
2012-08-19 11:23 ` Peter Maydell
2012-08-19 11:36 ` Avi Kivity
2012-08-21 4:48 ` liu ping fan
2012-08-21 8:57 ` Avi Kivity
2012-08-21 9:25 ` liu ping fan
2012-08-21 10:13 ` Avi Kivity
2012-08-21 11:18 ` liu ping fan
2012-08-21 12:41 ` Avi Kivity
2012-08-24 9:47 ` liu ping fan
2012-08-19 12:03 ` Peter Maydell
2012-08-19 13:05 ` Blue Swirl
2012-08-19 10:10 ` Avi Kivity [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5030BB87.6010505@redhat.com \
--to=avi@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=qemu-devel@nongnu.org \
--cc=qemulist@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.