From: Avi Kivity <avi@redhat.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: qemu-devel <qemu-devel@nongnu.org>, Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v2 1/2] memory: Fix old portio word accesses
Date: Mon, 19 Sep 2011 16:09:24 +0300 [thread overview]
Message-ID: <4E773F04.9000102@redhat.com> (raw)
In-Reply-To: <4E773BD5.8020105@web.de>
On 09/19/2011 03:55 PM, Jan Kiszka wrote:
> >
> > The trick of having a way to register N callbacks with one shot is worth
> > growing. Ideally each register in a BAR would have a callback and we'd
> > do something like
> >
> > MemoryRegionOps mydev_ops = {
> > .registers = {
> > { MYDEV_REG_x, 4, 4, mydev_reg_x_read, mydev_reg_x_write, },
> > ...
> > },
> > }
> >
> > with hints to the core like "this register sits at this offset, use it
> > for reads instead of a callback", or, "this is a read-only register".
>
> This has pros and cons. If you have n registers to dispatch, you then
> have to write n function prologues and maybe epilogues instead of just
> one. Specifically if the register access is trivial, that could case
> quite some LoC blowup on the device side.
>
> What may have a better ratio are generic register get/set handlers.
>
With C++ pointers-to-members and pointers-to-member-functions, you
actually get some nice representation:
class MyDev {
void reg_1_read(...) { return some_computation(); }
void reg_1_write(...) { do_something(); }
uint32_t reg_2;
void reg_2_write(...) { reg_2 = value; do_something(); }
uint64_t reg_3;
static const Register registers[] = {
Register(REG_1, &MyDev::reg_1_read, &MyDev::reg_1_write),
Register(REG_2, &MyDev::reg_2, &MyDev::reg_2_write),
Register(REG_1, &MyDev::reg_3),
};
};
... and the Register class generates the appropriate accessors. We can
emulate some of this with macros, but the conversion from opaque to the
actual type will always be ugly.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2011-09-19 13:09 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-18 12:44 [Qemu-devel] [PATCH 1/2] memory: Fix old portio word accesses Jan Kiszka
2011-09-18 12:51 ` [Qemu-devel] [PATCH v2 " Jan Kiszka
2011-09-18 15:37 ` Avi Kivity
2011-09-18 15:43 ` Jan Kiszka
2011-09-18 15:45 ` Avi Kivity
2011-09-18 16:28 ` Jan Kiszka
2011-09-18 16:49 ` Avi Kivity
2011-09-18 19:07 ` Jan Kiszka
2011-09-19 12:19 ` Avi Kivity
2011-09-19 12:32 ` Jan Kiszka
2011-09-19 12:42 ` Avi Kivity
2011-09-19 12:55 ` Jan Kiszka
2011-09-19 13:09 ` Avi Kivity [this message]
2011-09-19 13:55 ` Gerd Hoffmann
2011-09-19 13:58 ` Avi Kivity
2011-09-26 13:30 ` Avi Kivity
2011-09-18 14:44 ` [Qemu-devel] [PATCH " Richard Henderson
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=4E773F04.9000102@redhat.com \
--to=avi@redhat.com \
--cc=jan.kiszka@web.de \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/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.