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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).