From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47223 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMSGP-0005zh-Dv for qemu-devel@nongnu.org; Wed, 09 Jun 2010 16:52:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMSGN-0001EG-UF for qemu-devel@nongnu.org; Wed, 09 Jun 2010 16:52:41 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:36244) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMSGN-0001E9-Ob for qemu-devel@nongnu.org; Wed, 09 Jun 2010 16:52:39 -0400 Received: by iwn10 with SMTP id 10so2184128iwn.4 for ; Wed, 09 Jun 2010 13:52:38 -0700 (PDT) Message-ID: <4C0FFF13.1060700@codemonkey.ws> Date: Wed, 09 Jun 2010 15:52:35 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support References: <1275954730-8196-1-git-send-email-aliguori@us.ibm.com> <201006090311.44188.paul@codesourcery.com> <4C0F9D42.80908@codemonkey.ws> <201006091530.25838.paul@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Paolo Bonzini , Glauber Costa , Paul Brook , qemu-devel@nongnu.org On 06/09/2010 03:47 PM, Blue Swirl wrote: > On Wed, Jun 9, 2010 at 2:30 PM, Paul Brook wrote: > >>>>> Because at some point the base tree will have to be written in C. >>>>> >>>> No. You can start with a completely empty machine. >>>> We don't/shouldn't need any machine specific C code. >>>> >>> I think you're missing the argument. I should be possible to create a >>> machine entirely from a FDT or via -device options. >>> >>> However, to continue to support the interfaces that we support today, it >>> will be necessary to have C code that manipulates a base device tree. >>> >>> When a user specifies '-M pc -hda foo.img' verses '-M versatilepb -hda >>> foo.img', the equivalent are two very different operations on a device >>> tree. The former adds an ide disk to the default controller and the >>> later potentially creates a new scsi bus and then adds a disk to a >>> specific bus. >>> >> AFAICS the current commandline options only result in simple addition of >> devices. They might add slightly different devices in slightly different >> places, but that's easy to accommodate by having the machine define a few >> standard device/bus IDs. >> >> IMO it's even more lame if -hda shops working when you supply a device tree. >> > The tree supplied by the user should label a bus node with a property > 'QEMU,hda'. The C version (called by the board) would be something > like setprop("/i440fx/pci.0/ide.0", "QEMU,hda"). QEMU should search > the device tree for such labels at startup. > That works for the very simple case of -hda, but what do you do for: -drive file=foo.img,bus=0,index=2 I think it's possible to come up with some form of solution once you start adding synthetic properties or dummy devices but ultimately I think it pollutes the device tree. I think the easiest way to support the interfaces we provide now is to just code the device tree manipulation in C. Regards, Anthony Liguori