Massive libxo-zation that breaks everything

Alfred Perlstein bright at
Wed Mar 4 18:31:49 UTC 2015

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.


> 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.

More information about the freebsd-current mailing list