Massive libxo-zation that breaks everything

[John Baldwin]

On Tuesday, March 03, 2015 09:09:43 AM David Chisnall wrote:
> Hopefully there's a lesson here that we can learn from: human-readable
> formats do not make good intermediate representations when communicating
> between tools.

I think this is actually an argument against libxo-ification in the one case 
where I've cringed a bit at the diffs: pciconf.  The current pciconf code is 
tailored to outputting something human readable.  For non-human output I would
probably generate different output (not just put tags on the human output)
because I would want the non-human output to be both more verbose and more
raw.  I think some other cases like 'netstat -s' are far more straightforward 
as the current output maps fairly well to the backing structure, but in 
general I would want machine-readable output that is closer to the structures 
than to the human-readable formatting of them.

For example, for something like 'mfiutil show drives', I would want the human 
readable format to stay as it is (it only highlights certain fields in the PD 
structures) but I would want the machine-readable format to basically output 
tagged versions of the backing structures from sys/dev/mfi/mfireg.h.  That way 
the machine-readable format has all of the data instead of only the subset 
that is presented in the human-readable output.

So while I am in general a big fan of having machine-readable output from 
tools (and I think it belongs in the base system, and I don't think you want a 
post-processing tool), I think there is a bit of a flawed assumption that says 
that I want the same data in the human-readable format that I want in the 
machine-readable format.  I, for one, don't.  I want the human-readable form 
more condensed.

> If your argument is about maintainability of these changes, then please
> point to concrete instances where the changes are complex and difficult to
> maintain.

When I've looked at the xo diffs for pciconf, my reaction has been "ugh, I 
guess I'm not going to work on pciconf again in the future because that's 
super ugly".  I don't object to the idea, I think I would just rather have a 
very different schema for machine-readable output.  I would probably want 
pciconf -l in that case to dump the entire PCI header (right now the human-
readable pciconf -l only dumps a subset), and I would want it to dump fields 
in capabilities that we don't currently bother printing (and that I don't 
think the human-readable output should print due to it being too obscure, 
etc.)

-- 
John Baldwin