WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xl: Special case tap/aio for disk validation
From: Kamala Narasimhan <kamala.narasimhan@xxxxxxxxx>
Date: Fri, 28 Jan 2011 09:43:19 -0500
Cc: "Kamala Narasimhan \(3P\)" <kamala.narasimhan@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Fri, 28 Jan 2011 06:44:22 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eGXZNWVTimuiHLDhQZNizyYen+XcjGeQqwcxJFLss0c=; b=CeDUTBWVFiUcN98GzVBfX3PiOkxxCqoTqUraWuGLT9cOd4qrNr0yqGIxPydab+Md3K cOEpdhYnq1eYaN906zmD6GF2x3emoqqcBCh51U1HgZPGk7iJZIH+87D4p3ZI2Teu642k Da/CpmUoduLrD/pGZDjjnn1AwgqlWWOHWgbsg=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=yA+hF63XxajfQQ4U0XVQqUiolX7UdBx4U57v7hRadGGn/yVXTBy1Nt6VqWUqtGoKaw 0qlv6ivksRg40VC7uQPboKXQPLMBGvoLgCMvhzMdpDGCC9P+Q5JjX4UceykPuFlPjaIY lzX0xFMR7NdX28bnUQHu1BQBwNl82psws+edw=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1296209178.14780.6993.camel@xxxxxxxxxxxxxxxxxxxxxx>
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>
References: <4D407A06.1050902@xxxxxxxxx> <alpine.DEB.2.00.1101271506410.7277@kaball-desktop> <4D41ABEA.2080802@xxxxxxxxx> <alpine.DEB.2.00.1101271740170.7277@kaball-desktop> <4D42223E.1080008@xxxxxxxxx> <1296209178.14780.6993.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.24 (X11/20101027)
> Several elements of the 'format:path,vdev:type,attrib' string are
> optional. Can we delineate those in some non-confusing way? Often man
> pages and the like use [], which would end up as (I think):
>       [format:]path,vdev[:type],attrib
>
Believe it or not I tried that!  It ended up looking very confusing which is why
I switched to explicit verbal description of whether or not a particular
attribute is mandatory.

> I don't know if that meets the non-confusing criterion though. I didn't
> initially notice the "Mandatory" tag (see comments on line-wrapping
> below). The thing the tag doesn't cover is how the punctuation binds to
> the mandatory vs. optional elements. Perhaps insert
>         The "format:" and ":type" elements are optional
> alongside the comment about not all attributes being required?
> 
Sure, if that helps.

> IanJ wrote a existing spec for vdev at one point. I thought it had been
> committed somewhere but I can't see it. I think the most recent version
> was
> http://lists.xensource.com/archives/html/xen-devel/2010-09/msg01329.html
> but perhaps IanJ can confirm. We should incorporate it, either by
> reference or as a separate chapter in the same document or something
> similar.
> 
Sure.

> The discussion of which backend corresponds to each option is useful
> from an implementation detail point of view but I'm not sure it is
> necessary as part of the documentation of the configuration syntax. It's
> liable get out of date IMHO. Perhaps those bits would be better as a
> comment alongside the implementation?
> 
I do agree this is an information a pure end user won't care about.  The
question then gets to who is the target audience for this document.  If it is
mostly developers, it might help for them to have this information.

> It's not clear where the deprecated block-dev-type and access-type
> attributes are acceptable. I think we can just say that multiple
> deprecated attributes are accepted before the first valid "format" type
> is discovered, with the last one taking precedence, or something along
> those lines.
>
Sure.

> Lastly, I think the doc should be line-wrapped to 80 columns, otherwise
> the autowrapping of the table like elements ends up quite hard to
> follow. e.g. it currently comes out looking like:
>         
>         Description:         Specifies the format of image file.
>         Supported values:    raw, qcow, qcow2, vhd 
>         Deprecated values:   None
>         Mandatory:           No. When not specified raw format is
>         assumed.  For a physical block device the format must be raw and
>         need not be explicitly specified.  For an image file the format
>         could be one of the supported values and when not specified
>         assumed to be raw.
>         Backend used:        For qcow/qcow2 qemu backend is u[...]
>
> should be (subject to my guessing where 80 columns actually is in this
> case):
> 
>         Description:         Specifies the format of image file.
>         Supported values:    raw, qcow, qcow2, vhd 
>         Deprecated values:   None
>         Mandatory:           No. When not specified raw format is assumed.  
> For a physical block device the format
>                              must be raw and need not be explicitly 
> specified.  For an image file the format could
>                              be one of the supported values and when not 
> specified assumed to be raw.
>         Backend used:        For qcow/qcow2 qemu backend is u[...]
>                              [...] etc 
> 
Yep, I will do that and send out a revised version.

Kamala

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>