From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1M92hV-0002jV-1z for qemu-devel@nongnu.org; Tue, 26 May 2009 15:52:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1M92hQ-0002jJ-47 for qemu-devel@nongnu.org; Tue, 26 May 2009 15:52:40 -0400 Received: from [199.232.76.173] (port=58617 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1M92hP-0002jG-Vh for qemu-devel@nongnu.org; Tue, 26 May 2009 15:52:36 -0400 Received: from rv-out-0708.google.com ([209.85.198.241]:31628) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1M92hP-0005sq-Ju for qemu-devel@nongnu.org; Tue, 26 May 2009 15:52:35 -0400 Received: by rv-out-0708.google.com with SMTP id c5so1381587rvf.22 for ; Tue, 26 May 2009 12:52:34 -0700 (PDT) Message-ID: <4A1C487B.90908@codemonkey.ws> Date: Tue, 26 May 2009 14:52:27 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Patch: Adding ability for qemu-img to create SCSI VMware disk images References: <4A16D5B8.50508@codemonkey.ws> <4A1BA22D.4040008@codemonkey.ws> <4A1BB1DE.3080600@redhat.com> In-Reply-To: <4A1BB1DE.3080600@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Aaron Mason , "qemu-devel@nongnu.org" Kevin Wolf wrote: > Anthony Liguori schrieb: > >> Aaron Mason wrote: >> >>> Who said the images had to be used for QEMU? As I said, I use the >>> utility primarily for creating VMware images. >>> >> If it's not useful for QEMU, then I don't see that it's worth >> maintaining within QEMU. >> > > Then I wonder why we have the compat6 option for VMDK. I would be rather > surprised if it was useful for qemu itself. > Yup. I don't like the compat6 patch either as it's pretty invasive. > FWIW, I know that SUSE had a use for these SCSI VMDKs and they carry a > local patch for it. I would prefer to have such things upstream, even if > it's just for exporting. After all, qemu-img is the Swiss army knife for > images. > If there's support for it, we can take it. I worry about adding features that aren't widely useful as they add complexity and make it hard to refactor things. Introducing BLOCK_FLAG_BUSLOGIC and BLOCK_FLAG_LSILOGIC seems very wrong to me. You're happy with it? Regards, Anthony Liguori > Kevin >