[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] xen-tmem-list-parse: fix ugly parse output
> From: Ian Jackson [mailto:Ian.Jackson@xxxxxxxxxxxxx] > 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@xxxxxxxxxx> > > > > Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |