Re: [PATCH] xen-tmem-list-parse: fix ugly parse output

[Dan Magenheimer <dan.magenheimer@oracle.com>]

> From: Ian Jackson [mailto:Ian.Jackson@eu.citrix.com]
> Subject: Re: [PATCH] xen-tmem-list-parse: fix ugly parse output
> 
> Ian Campbell writes ("Re: [PATCH] xen-tmem-list-parse: fix ugly parse output"):
> > On Wed, 2012-11-14 at 00:08 +0000, Dan Magenheimer wrote:
> >
> > > > Signed-off-by: Dan Magenheimer <dan.magenheimer@oracle.com>
> >
> > Acked-by: Ian Campbell <ian.campbell@citrix.com> and applied, sorry for
> > the delay.
> 
> I'm happy to backport this to 4.2.  Since none of this is tested by
> the autotests and the change is self-contained, there is no point
> waiting to see if it survives in -unstable and I have done so right
> away.
> 
> As for 4.1, I think that's really very much in the deep freeze and
> receiving essential bug/compatibility/security fixes only so I would
> be inclined to punt on this patch.
> 
> I have another comment though:
> 
>   The program xen-tmem-list-parse parses the output of xm/xl tmem-list
>   into human-readable format.  A missing NULL terminator sometimes
>   causes garbage to be spewed where the two-letter pool type
>   should be output.
> 
> Would it not be much better if  xl tmem-list  produced a sane format
> to start with ?  I haven't seen what the old and new formats are like
> but in general I think  xl foo-list  should produce information useful
> to humans.
> 
> In xl for the future we should be providing json output for things
> which need to be machine-readable.  This may need a transition plan of
> course.

The real consumer of the tmem-list is a toolstack.  It contains a wealth
of information that might be useful to automatic balancing tools
(for balancing across multiple machines, not so much VMs within a single
machine).  So a long-winded-hard-to-parse-but-human-readable format
didn't seem wise.  Also, because it was not clear at the time (and
still isn't) which of the listed data would be useful, or if more
would be even more useful, I chose a format where more or less
data could be provided forwards- and backwards-compatible across
multiple generations of tools parsing the data.

BUT, the data is also useful for debugging and for experimenters
trying tmem to observe what is going on (I often used
"watch -d 'xm tmem-list | xen-tmem-list-parse'"),
so I hacked up a parsing program to make it human readable.

That's just the history... I am very open to a different approach
as long as it meets the needs described above.  Someone with
a different set of skills than I will need to take it on though.

Thanks,
Dan