This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] xl: Special case tap/aio for disk validation

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xl: Special case tap/aio for disk validation
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Thu, 27 Jan 2011 15:35:27 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Kamala Narasimhan \(3P\)" <kamala.narasimhan@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Thu, 27 Jan 2011 07:36:16 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19777.36262.691401.791181@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <4D407A06.1050902@xxxxxxxxx> <alpine.DEB.2.00.1101271506410.7277@kaball-desktop> <19777.36262.691401.791181@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, 2011-01-27 at 15:22 +0000, Ian Jackson wrote:
> Stefano Stabellini writes ("Re: [Xen-devel] [PATCH] xl: Special case tap/aio 
> for disk validation"):
> > - A fix for parse_disk_config.
> > The new algorithm should assume format=raw and ignore tap:, tap2:, aio:,
> > tapdisk:, ioemu:, until it gets to a real disk format (qcow:, qcow2:,
> > vhd:) or the file name.
> You can recognise the filename by the fact that it starts with a "/",
> since most of our stuff doesn't work with relative pathnames for block
> devices and we don't want it to try to make it work now.

FWIW xend notices a relative path and wacks a "/dev/" on the front.

> So the specification string should always be either
>    someprefix:[stuff]
> in which case you strip off someprefix: (perhaps making a note of its
> implications) or /somepath
> in which case you've got to the end and know what to do.

Shall we pre-deprecate the someprefix: along with all the
tap:{aio,ioemu,FOO}: stuff while we are at this? IOW the syntax we want
to actually support going forward would be:
with the toolstack being at liberty to best decide how to achieve the
necessary format support? (optionally raw: as the default). All the rest
of the format is really semantically meaningless and supported only for
compatibility with existing configuration files.


Xen-devel mailing list