On 3/4/15 8:21 AM, John Baldwin wrote:
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.
+1
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.)
I actually agree on this and this is why I was upset that the more
straightforward GSoC code was shot down in favor of this. That said
don't we all need to look at the greater good when making software and
we have some consensus on this so its worth going forward imo.
We can agree on something even though it might make hairs stand up or we
just stagnate.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
