On 04.03.2015 19:21, 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. 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 agree that adding machine-readable output + separate option on a per-tool basis, when it is really needed, is more clean approach which don't break Unix way of things. In such case we don't intermix structured representation with human readable, so the chances that a bug in one representation code flow will affect other one are minimal unlike in unified libxo approach, which already demonstrate this weakness. -- http://ache.vniz.net/ _______________________________________________ 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"
