From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60945) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5dRh-0008Fc-Gx for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:59:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5dRb-0004uk-Nw for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:59:37 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51407) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5dRb-0004ua-Fe for qemu-devel@nongnu.org; Mon, 19 Sep 2011 08:59:31 -0400 Message-ID: <4E773CAF.9060202@redhat.com> Date: Mon, 19 Sep 2011 15:59:27 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E75EA08.4090809@web.de> <4E7614CC.4000206@redhat.com> <4E761C66.9010208@web.de> <4E762064.6010108@redhat.com> <4E7640C8.8040600@web.de> <4E77322B.2040008@redhat.com> <4E7735B4.1030903@web.de> <4E77378E.80204@redhat.com> <4E773A2D.3010407@web.de> In-Reply-To: <4E773A2D.3010407@web.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] isa: Avoid using obsolete memory_region_set_offset for old portio 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:48 PM, Jan Kiszka wrote: > > > > Ah: > > > > - /* If we see a hole, break the region. */ > > + /* If we see a new offset, break the region. */ > > > > > > But, sorry for being slow, I don't see why it requires a core update > > (other for adding mrp->offset). > > So far we matched accesses in find_portio by considering the portio > offset as well. If we want to replace the region offset with the portio > one (which confines legacy to a legacy-only place), we need to make the > portio offset a pure correction value on handler invocation and exclude > it from any range matching. And that means an old_portio memory region > can only describe one range starting exactly at MemoryRegion::addr. Thanks for the explanation. But I think you're trying to remove ->offset by moving it somewhere else. That's not removal, that's renaming, and it reduces functionality for other old_portio users. If users need absolute addresses, then we should provide them via set_offset(), not pretend the need doesn't exist. (btw, another way to emulate set_offset() is via aliases, as detailed in the other thread). > > > > >> > >> > They all use the same handler, so you need to split e.g. > >> > sh7750_io_memory into six MemoryRegionsOps. Or use tricks with > >> aliases - > >> > have one giant 4G region with one handler, and map six 4k aliases into > >> > the system address space. > >> > >> Looks more like 3 regions with one alias each. But we likely need to > >> disentangle all that logic first. I would be surprised if there wasn't a > >> more readable way to express it via the memory API. > >> > > > > Depends if you subscribe to the "blindly make it work exactly the same > > way" or "understand the details and rewrite it cleanly" brands of > > masochism. > > We generally used to convert from APIv to APIv by adding legacy > wrappers, rarely removing any of them. This doesn't scale, but - granted > - it requires some masochism to make progress. > Wrappers reduce the risk of regression from a bad conversion by a tired coder. But yes, they increase the amount of cruft immensely. -- error compiling committee.c: too many arguments to function