From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40540) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOQlx-0000Dv-NA for qemu-devel@nongnu.org; Mon, 23 May 2011 04:45:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QOQlw-00078b-W5 for qemu-devel@nongnu.org; Mon, 23 May 2011 04:45:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42613) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QOQlw-00078U-OF for qemu-devel@nongnu.org; Mon, 23 May 2011 04:45:56 -0400 Date: Mon, 23 May 2011 11:45:49 +0300 From: Gleb Natapov Message-ID: <20110523084549.GL28399@redhat.com> References: <4DD56543.9020404@web.de> <20110519185019.GK27310@redhat.com> <4DD567B5.1060205@web.de> <20110520072358.GL27310@redhat.com> <4DD61ADD.9050103@web.de> <20110520112534.GM27310@redhat.com> <4DD8C03E.3020904@redhat.com> <20110522084142.GS27310@redhat.com> <4DD8EB14.8050305@web.de> <4DD8F397.2000805@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DD8F397.2000805@redhat.com> Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Jan Kiszka , qemu-devel On Sun, May 22, 2011 at 02:29:27PM +0300, Avi Kivity wrote: > On 05/22/2011 01:53 PM, Jan Kiszka wrote: > >On 2011-05-22 10:41, Gleb Natapov wrote: > >>> The chipset knows about the priorities. How to communicate them to > >>> the core? > >>> > >>> - at runtime, with hierarchical dispatch of ->read() and ->write(): > >>> slow, and doesn't work at all for RAM. > >>> - using registration order: fragile > >>> - using priorities > >>> > >> - by resolving overlapping and registering flattened list with the core. > >> (See example above). > > > >[Registration would happens with the help of the core against the next > >higher layer.] > > > >To do this, you need to > > - open-code the resolution logic at every level (very bad idea) > > - provide library services to obtain a flattened representation > > > >Please try to specify such an API without any parameters that are > >priority-like. > > Another way of saying the same thing: having the chipset code > resolve conflicts, and having the chipset code assign priorities, > are equivalent. But having priorities allows flattening to take > place without further involvement of the chipset code. > Yes, that's basically sums it up. My main concern with API was that it was not clear how two independent pieces of code would know how to assign priorities. But if all registrations happen hierarchically there will be no such "independent pieces of code". -- Gleb.