From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39526) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPCiO-0002kE-IA for qemu-devel@nongnu.org; Tue, 01 May 2012 09:02:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SPCiM-0004VK-La for qemu-devel@nongnu.org; Tue, 01 May 2012 09:02:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SPCiM-0004Un-Dq for qemu-devel@nongnu.org; Tue, 01 May 2012 09:01:58 -0400 Message-ID: <4F9FDEBC.2030806@redhat.com> Date: Tue, 01 May 2012 16:01:48 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4F9D797E.500@ilande.co.uk> <4F9D97F3.8080608@codemonkey.ws> <4F9E5028.7010306@redhat.com> <4F9E82C7.10706@ilande.co.uk> <4F9E9268.70408@redhat.com> <4F9E9569.5000700@redhat.com> <4F9FD997.9000403@redhat.com> <4F9FDA38.6030108@redhat.com> <4F9FDB80.4020604@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Memory API: handling unassigned physical memory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Mark Cave-Ayland , qemu-devel@nongnu.org, Anthony Liguori On 05/01/2012 03:49 PM, Peter Maydell wrote: > On 1 May 2012 13:48, Avi Kivity wrote: > > On 05/01/2012 03:43 PM, Peter Maydell wrote: > >> On 1 May 2012 13:42, Avi Kivity wrote: > >> > sysbus should just die. > >> > >> Totally agreed. It's not going to go quietly though... > > > > Not if you keep suggesting workarounds when I tell unsuspecting > > developers to qomify their devices. > > When QOM supports (1) exporting gpio signals and (2) > exporting memory regions, then it will be providing the > main things that sysbus provides. (Sysbus today is essentially > "I need a device that exports some memory regions and some > I/O pins".) At that point it will be sensible to say "convert > your sysbus devices to QOM". Until QOM is actually able to > provide the functionality, it's not a workable replacement. Doesn't property (or however it's phrased) provide the functionality for memory? But I agree. -- error compiling committee.c: too many arguments to function