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.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home