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: Kamala Narasimhan <kamala.narasimhan@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] xl: Special case tap/aio for disk validation
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Fri, 28 Jan 2011 10:06:18 +0000
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 02:06:53 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D42223E.1080008@xxxxxxxxx>
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> <4D41ABEA.2080802@xxxxxxxxx> <alpine.DEB.2.00.1101271740170.7277@kaball-desktop> <4D42223E.1080008@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Fri, 2011-01-28 at 01:56 +0000, Kamala Narasimhan wrote:
> >>> Following these notes, we need:
> >>>
> >>> - a document describing this in full details.
> >> Would a txt file do?  Where would it go - under tools/examples where other 
> >> config options are described (albeit in a config file and not a separate 
> >> file)?
> > 
> > Yep. A text file under docs will be perfect.
> > 
> > 
> >  
> Attached is a first stab at this for your perusal.  It is mostly based
> on the discussion we had in this thread.  Please let me know any/all
> changes you would recommend.
> 
> I am sending this in advance as anything I have captured wrong here
> would mean it is likely that the code changes I am making right now
> could also be wrong!  So please do respond back if I have incorrectly
> captured any  conclusion we arrived at in terms of the
> supported/deprecated attributes for the disk configuration option.
> Thanks!

Nice one. I have a handful of minor comments.

There's a bunch of examples of this stuff in tools/examples, much of
which would benefit from the addition of a reference to this document in
its eventual resting place and sanity checking for adherence to what the
document says. It's hard to believe (ok, not really) that we don't have
any other in tree documentation of any of the other configuration syntax
other than those examples (and some vagueish lists in
tools/python/README.*) but it does seem to be the case :-(. Perhaps
there is something in the wiki or else maybe this document can be the
seed around which the rest grows...

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

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?

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.

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?

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.

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 


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

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