From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN3FF-0005kR-K1 for qemu-devel@nongnu.org; Thu, 19 May 2011 09:26:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QN3FE-0005ok-Hd for qemu-devel@nongnu.org; Thu, 19 May 2011 09:26:29 -0400 Received: from thoth.sbs.de ([192.35.17.2]:24766) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QN3FE-0005oQ-91 for qemu-devel@nongnu.org; Thu, 19 May 2011 09:26:28 -0400 Message-ID: <4DD51A82.7060205@siemens.com> Date: Thu, 19 May 2011 15:26:26 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <4DD3D236.90708@siemens.com> <4DD3D95E.2060105@redhat.com> <4DD3E1B3.3020405@siemens.com> <4DD3E47F.9060104@redhat.com> <4DD3E782.8090208@siemens.com> <4DD3E8D6.6090807@redhat.com> <20110519090851.GD28399@redhat.com> <4DD4DE8E.8030402@redhat.com> <20110519091404.GE28399@redhat.com> <4DD5029D.6000700@redhat.com> <20110519115405.GG28399@redhat.com> <4DD505C4.6010604@redhat.com> <4DD50B17.7000205@siemens.com> <4DD511FB.3080901@redhat.com> <4DD51413.1050202@siemens.com> <4DD51468.7050509@redhat.com> <4DD51531.7000701@siemens.com> <4DD515F9.1020902@redhat.com> In-Reply-To: <4DD515F9.1020902@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Memory API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: qemu-devel , Gleb Natapov On 2011-05-19 15:07, Avi Kivity wrote: > On 05/19/2011 04:03 PM, Jan Kiszka wrote: >> On 2011-05-19 15:00, Avi Kivity wrote: >>> On 05/19/2011 03:58 PM, Jan Kiszka wrote: >>>>> >>>>> Eventually we may make the memory API a sub-API of qdev. I don't want >>>>> to start with that however, the change is large enough already. >>>> >>>> Touching all devices again at that point to change the way they register >>>> regions may not be the best approach. I would try to consolidate the >>>> refactoring work that affects the majority of device models. >>> >>> The risk is that the entire work will be stalled if it requires too much >>> effort. >> >> Then we could still switch one gear down, converting at least some >> exemplary devices completely to demonstrate that the API changes fit >> into the big picture. > > My plan is: > > - post RFC v1 with updated API in patch form > - RFC v2 with implementation + significant fraction of PC devices coverted > - PATCH v3 with full conversion an elimination of the old API And when introducing hierarchical registration, we will have to go through all of this once again. Plus the API may have to be changed again if it does not fulfill all requirements of the hierarchical region management. And we have no proof that it allows an efficient core implementation. Before touching any device at all, what about building the infrastructure to manage and address memory regions hierarchically via qdev first? That could be started on a green field, then applied to the PC architecture, and finally rolled out for all. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux