From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=41638 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OMML9-0002jv-73
	for qemu-devel@nongnu.org; Wed, 09 Jun 2010 10:33:14 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <paul@codesourcery.com>) id 1OMMJR-0005BD-L5
	for qemu-devel@nongnu.org; Wed, 09 Jun 2010 10:31:26 -0400
Received: from mail.codesourcery.com ([38.113.113.100]:43528)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <paul@codesourcery.com>) id 1OMMJR-0005At-Ce
	for qemu-devel@nongnu.org; Wed, 09 Jun 2010 10:31:25 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
Date: Wed, 9 Jun 2010 15:30:25 +0100
References: <1275954730-8196-1-git-send-email-aliguori@us.ibm.com>
	<201006090311.44188.paul@codesourcery.com>
	<4C0F9D42.80908@codemonkey.ws>
In-Reply-To: <4C0F9D42.80908@codemonkey.ws>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201006091530.25838.paul@codesourcery.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Paolo Bonzini <pbonzini@redhat.com>, Glauber Costa <glommer@redhat.com>, qemu-devel@nongnu.org

> >> 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.

Paul