From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KNU5U-0005n4-2R
	for qemu-devel@nongnu.org; Mon, 28 Jul 2008 10:52:36 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KNU5T-0005kV-Dw
	for qemu-devel@nongnu.org; Mon, 28 Jul 2008 10:52:35 -0400
Received: from [199.232.76.173] (port=50667 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KNU5T-0005kI-A8
	for qemu-devel@nongnu.org; Mon, 28 Jul 2008 10:52:35 -0400
Received: from mx1.redhat.com ([66.187.233.31]:52531)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kraxel@redhat.com>) id 1KNU5S-0007nT-Hc
	for qemu-devel@nongnu.org; Mon, 28 Jul 2008 10:52:34 -0400
Message-ID: <488DDD2C.10308@redhat.com>
Date: Mon, 28 Jul 2008 16:52:28 +0200
From: Gerd Hoffmann <kraxel@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 1/7] xen: groundwork for xen support
References: <1217251078-6591-1-git-send-email-kraxel@redhat.com>
	<1217251078-6591-2-git-send-email-kraxel@redhat.com>
	<488DD206.8040404@codemonkey.ws>
In-Reply-To: <488DD206.8040404@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
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.gnu.org/pipermail/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: xen-devel@lists.xensource.com, qemu-devel@nongnu.org

>> +/* xen_machine.c */
>> +extern QEMUMachine xenpv_machine;
>> +extern QEMUMachine xenfv_machine;
> 
> Why does xenfv need its own machine type?

This is how xen's qemu-dm handles it at the moment and I've decided to
do it the same way for simplicity.  I think qemu could also figure it
using a hypercall.

>> -    /* XXX: this should not be: some embedded targets just have flash */
>> +    /* need a disk for this machine to boot ? */
>> +    /* XXX: add embedded targets which just have flash */
>> +    nodisk_ok = 0;
>> +    if (0 == strcmp(machine->name, "xenpv"))
>> +    nodisk_ok = 1;
>>      if (!linux_boot && net_boot == 0 &&
>> -        nb_drives_opt == 0)
>> +        !nodisk_ok && nb_drives_opt == 0)
>>          help(1);
> 
> This patch is pretty clean with the exception of this bit.  I think a
> cleaner way to do this would be to let the machine types specify whether
> a disk is needed or not.

Agreed, I'll make it a machine_type field.

thanks,
  Gerd

-- 
http://kraxel.fedorapeople.org/xenner/