From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JouvU-0000wH-Me for qemu-devel@nongnu.org; Thu, 24 Apr 2008 02:27:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JouvT-0000vk-2d for qemu-devel@nongnu.org; Thu, 24 Apr 2008 02:27:24 -0400 Received: from [199.232.76.173] (port=44566 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JouvS-0000vf-OD for qemu-devel@nongnu.org; Thu, 24 Apr 2008 02:27:22 -0400 Received: from mx20.gnu.org ([199.232.41.8]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JouvS-0003ji-J6 for qemu-devel@nongnu.org; Thu, 24 Apr 2008 02:27:22 -0400 Received: from mx2.suse.de ([195.135.220.15]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Joufi-0005ja-8G for qemu-devel@nongnu.org; Thu, 24 Apr 2008 02:11:06 -0400 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx2.suse.de (Postfix) with ESMTP id ADA0844C48 for ; Thu, 24 Apr 2008 08:11:03 +0200 (CEST) Message-ID: <48102345.6010703@suse.de> Date: Thu, 24 Apr 2008 08:05:57 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] qemu-img: Create SCSI VMDK disks References: <480E0ADC.8010000@suse.de> <023701c8a57f$448e8680$0201a8c0@zeug> In-Reply-To: <023701c8a57f$448e8680$0201a8c0@zeug> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Sebastian Herbszt schrieb: >> This patch introduces a new option to qemu-img: -s indicates for VMDK >> images that the image is meant to be used as SCSI disk. Depending on >> the switch "ide" or "buslogic" is written to the image as adapter type. > > Any particular reason you chose "buslogic" over "lsilogic"? > What about adding "-a" (adapter) option like in vmware-vdiskmanager? Not really. It's just what was needed internally (read: what I was asked to implement in a free minute). I certainly wouldn't oppose if anyone wanted to extend it to be more generic. Kevin