[Patch] updated: Add JSON and XML output to pciconf (libxo support - D1206)

[Stefan Esser]

Am 08.12.2014 um 14:39 schrieb se at freebsd.org:
>> >From se at FreeBSD.org  Mon Dec  8 14:34:01 2014
> Return-Path: <se at FreeBSD.org>
> X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
[...]

Sorry for the malformed message, I have no idea why the mail header
became part of the message body. (The message was sent as a "bounce"
by "mutt", and that used to work for decades ...)

Content of this message should just have been my update on the patch
that adds XO support to pciconf and which is available for review as
D1206 on reviews.freebsd.org (https://reviews.freebsd.org/D1206).

Regards, STefan


And here is just the relevant text from that mal-formatted message:

> Update after review by Phil Shafer and extend to cover errors and capabilities
> 
> Summary:
> 
> This version contains many fixes to issues pointed out by Phil and
> a number of further enhancements:
> - Use of XO lists and instances to structure the information
> - Descriptive identifiers instead of abbreviations
> - Addition of XO support to PCI/PCIe error reporting
> - Addition of XO support to PCI/PCIe capability information printing
> 
> I do not have access to a PCI or PCI-Express Spec. with information on 
> the capabilities and their specified names, but have only used publicly
> available information to select XML/JSON labels. A pointer to a freely
> available specification of PCI/PCIe capabilities (just the path that 
> might help chose good names for data fields) would be highly appreciated.
> 
> Test Plan: 
> 
> This version of pciconf should generate 100% identical output, except 
> when one of the structured XO formats is requested.
> 
> Please test with:
> 	pciconf -lbecv
> 
> I do not know whether the labels used for XML amd JSON output of PCI/PCIe
> capabilities are well chosen. Several names are very long, but I wanted to 
> avoid cryptic abbreviations. Suggestions for better or more correct names
> are welcome.
> 
> I could not test output of Intel or AMD (Hyper Transport) specific 
> capabilities (my Intel system uses SATA AHCI, but I do not see that in 
> the reported capabilities; I do not have any FreeBSD systems on AMD 
> hardware, currently).
> 
> I'm adding a few reviewers (jhb because he did the initial commit of cap.c
> and kib because of the HT specific information that I cannot test). I hope 
> you don't mind being selected as potential reviewers.