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 8/9] xl: xl block-attach -N (dry run) option

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 8/9] xl: xl block-attach -N (dry run) option
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Fri, 3 Jun 2011 12:16:24 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 03 Jun 2011 04:19:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1307098008.775.368.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: <1307037346-31251-1-git-send-email-ian.jackson@xxxxxxxxxxxxx> <1307037346-31251-2-git-send-email-ian.jackson@xxxxxxxxxxxxx> <1307037346-31251-3-git-send-email-ian.jackson@xxxxxxxxxxxxx> <1307037346-31251-4-git-send-email-ian.jackson@xxxxxxxxxxxxx> <1307037346-31251-5-git-send-email-ian.jackson@xxxxxxxxxxxxx> <1307037346-31251-6-git-send-email-ian.jackson@xxxxxxxxxxxxx> <1307037346-31251-7-git-send-email-ian.jackson@xxxxxxxxxxxxx> <1307037346-31251-8-git-send-email-ian.jackson@xxxxxxxxxxxxx> <1307037346-31251-9-git-send-email-ian.jackson@xxxxxxxxxxxxx> <1307098008.775.368.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Ian Campbell writes ("Re: [Xen-devel] [PATCH 8/9] xl: xl block-attach -N (dry 
run) option"):
> On Thu, 2011-06-02 at 18:55 +0100, Ian Jackson wrote:
> > @@ -4041,6 +4053,22 @@ int main_blockattach(int argc, char **argv)
> >  
> >      disk.backend_domid = be_domid;
> >  
> > +    if (dry_run) {
> > +        /* fixme: this should be generated from the idl */
> What capabilities do you think we want here?
> Does it need to be human or machine readable or both? What should the
> syntax be?

It should be both human- and machine-readable, although I'm not asking
right now for the machine parser to exist.  I don't mind what the
syntax is but one value per line is probably a good start.

> Do you think we want functions to get a string of any field or just the
> entire structure?

Just the entire structure.

> In principal making the idl generator to this is pretty easy. However if
> what it produces is only useful to xl because other toolstacks need e.g.
> xml or json output (or just human syntax which matches their style) then
> I'm not sure what the best answer is.

JSON would be a good concrete syntax.

> We could support multiple syntaxes is in libxl (_to_string, _to_xml,
> _to_json etc etc), supply an IDL driven pretty-printer-printer library
> (so toolstacks can easily write their own) or supply a libxl function
> which takes a callback fn "void fn(const char *field, const char
> *value)" etc.

If we had a competent JSON pretty-printer it would do as the
human-readable output too.  We shouldn't be encouraging XML :-).

> What do you think? (I think I lean towards the final option, unless a
> single hardcoded syntax is thought to be sufficient).

The prototype you suggest is not sufficient because field members may
be structures, so the whole thing needs to be recursive.  If you want
reasonable output from a recursive pretty-printer you need to pass an
indent level etc.


Xen-devel mailing list

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