From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36485) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5dbF-0001Cl-HF for qemu-devel@nongnu.org; Mon, 19 Sep 2011 09:09:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5dbE-0006zW-Kb for qemu-devel@nongnu.org; Mon, 19 Sep 2011 09:09:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58195) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5dbE-0006zQ-DV for qemu-devel@nongnu.org; Mon, 19 Sep 2011 09:09:28 -0400 Message-ID: <4E773F04.9000102@redhat.com> Date: Mon, 19 Sep 2011 16:09:24 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E75E7A4.50702@web.de> <4E75E96E.90101@web.de> <4E761051.9000204@redhat.com> <4E76119F.5040004@web.de> <4E761220.3080707@redhat.com> <4E761C20.4040609@web.de> <4E76212A.20000@redhat.com> <4E764185.8020500@web.de> <4E773365.9010008@redhat.com> <4E773644.8020005@web.de> <4E7738C5.6050504@redhat.com> <4E773BD5.8020105@web.de> In-Reply-To: <4E773BD5.8020105@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 1/2] memory: Fix old portio word accesses List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , Richard Henderson 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