From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40888 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMLka-0002ca-81 for qemu-devel@nongnu.org; Wed, 09 Jun 2010 09:55:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMLkT-0006P2-Tu for qemu-devel@nongnu.org; Wed, 09 Jun 2010 09:55:22 -0400 Received: from mail-yx0-f173.google.com ([209.85.213.173]:33082) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMLkT-0006Op-Rj for qemu-devel@nongnu.org; Wed, 09 Jun 2010 09:55:17 -0400 Received: by yxk8 with SMTP id 8so1215565yxk.4 for ; Wed, 09 Jun 2010 06:55:16 -0700 (PDT) Message-ID: <4C0F9D42.80908@codemonkey.ws> Date: Wed, 09 Jun 2010 08:55:14 -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> <201006081636.12242.paul@codesourcery.com> <4C0E6894.9000901@redhat.com> <201006090311.44188.paul@codesourcery.com> In-Reply-To: <201006090311.44188.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: Paolo Bonzini , Glauber Costa , qemu-devel@nongnu.org On 06/08/2010 09:11 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. We could force users to these explicit operations instead of the generic options we provide today but we would certain end up having our users hate us as a result. > When I submitted the original qdev code I also posted a proof-of-concept patch > that built the whole machine based on a config file with no hardcoded > knowledge of the machine structure. > And in your proof-of-concept patches, you couldn't use -hda or any of the other command line options that are currently used. To support those things, something would have to understand the device tree well enough to know what -hda is supposed to mean. That's the point of MachineCore. >> Of course you have to decide where to stop allowing customization, but >> anyway it will be significantly more complex than a QemuOpts config >> file. QemuOpts obviously doesn't have the flexibility to create an >> entire device tree. >> > Why not? > The current -device option already provides the majority of the functionality > required. Most of the missing bits are incomplete qdev conversion. > I'm not saying that creating a whole machine via -device options is an elegant > solution (hence the interest in things like FDT) but in I see no reason why it > shouldn't work. > > IMO all uses of the no_user flag are bugs resulting from incomplete/incorrect > qdev conversions. > I don't disagree. Regards, Anthony Liguori