From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LRWyp-0001dy-Nd
	for qemu-devel@nongnu.org; Mon, 26 Jan 2009 14:18:43 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LRWyo-0001dU-So
	for qemu-devel@nongnu.org; Mon, 26 Jan 2009 14:18:43 -0500
Received: from [199.232.76.173] (port=44044 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LRWyo-0001dN-MF
	for qemu-devel@nongnu.org; Mon, 26 Jan 2009 14:18:42 -0500
Received: from mx20.gnu.org ([199.232.41.8]:52592)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <uril@redhat.com>) id 1LRVHU-0007C8-R4
	for qemu-devel@nongnu.org; Mon, 26 Jan 2009 12:29:53 -0500
Received: from mx2.redhat.com ([66.187.237.31])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <uril@redhat.com>) id 1LROLy-0002BR-Rx
	for qemu-devel@nongnu.org; Mon, 26 Jan 2009 05:06:03 -0500
Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26])
	by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0QA41P5010809
	for <qemu-devel@nongnu.org>; Mon, 26 Jan 2009 05:04:01 -0500
Message-ID: <497D8A8E.2050406@redhat.com>
Date: Mon, 26 Jan 2009 12:03:58 +0200
From: Uri Lublin <uril@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] [RFC] A more consistent qemu-img create with a
 relative path backing file
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: qemu-devel@nongnu.org
Cc: Cyril Plisko <cplisko@redhat.com>, Uri Lublin <uril@redhat.com>, Igor Lvovsky <ilvovsky@redhat.com>

Hello,

Currently there is a difference in the way "qemu-img create -b" opens a backing 
file and the way bdrv_open does that, when the backing file path is relative. 
The former calculates the relative path from the CWD, while the latter 
calculates the relative path from the filename's directory. This inconsistency 
force the user to change-dir into the created-file directory when creating a new 
image.

For example, let the backing file be <images>/dir1/g1.qcow2
and let image to be  created be      <images>/dir2/g2.qcow2, the steps I need to 
take are:
1. cd <images>/dir2
2. qemu-img create -b ../dir1/g1.qcow2 -f qcow2 g2.qcow2
3. cd -

If I skip step 1 then both following options fail (let my CWD be e.g <images>)
  a. qemu-img create -b ../dir1/g1.qcow2 -f qcow2 dir2/g2.qcow2  or
  b. qemu-img create -b dir1/g1.qcow2 -f qcow2 dir2/g2.qcow

Option (a) fails to open the backing file and "qemu-img create" fails
Option (b) "qemu-img create" succeeds, but bdrv_open fails (e.g. "qemu-img info 
dir2/g2.qcow"), as the backing file path calculation result in 
<images>/dir2/dir1/g1.qcow2.

We suggest that the path calculation (full path from relative) will be done the 
same for qemu-img create and for qemu-img info (bdrv_open), making their 
behavior consistent. Thus qemu-img create will first calculate the backing file 
path relative to the created-file path (using path_combine), making (1)+(2)+(3) 
and (a) above the same.

In order to keep current behavior working, we suggest adding a new flag (-s or 
-r) to qemu-img create for the new suggested behavior.

Would such a patch be acceptable ?

Thanks,
    Uri.