Adding libxo support to ifconfig (XML / JSON output)

[paige_paige.bio]

Summary

This change introduces a --libxo <fmt> option to /sbin/ifconfig which provides a means to export interface state data as JSON, XML,
or HTML. I'm considering removing HTML, and might reccomend the same for usr.bin/netstat. I'm planning to reccomend another patch I'm currently
authoring for ifconfig that would add support for interface creation / configuration from an XML file which would allow you persist interface
configuration state easily across reboots by exporting to XML and restoring from XML. I would also like to reccomend a patch for sbin/route
which would add support for creating routes from XML created by usr.bin/netstat at that point. I figure that these should probably all be
in a different scope just considering the length of this change.

Test Plan

There are a few things which apply here:

• /usr/src/contrib/libxo/xolint/xolint.pl /usr/src/sbin/ifconfig/*.c
• bash -c 'diff -y <(/sbin/ifconfig) <(./ifconfig)' [ensuring that the original text output is consistent with the original version of

ifconfig]

• testing JSON output with jq: ./ifconfig --libxo json | jq
• testing XML output with xmllint or similar tools: ./ifconfig --libxo xml | xmllint --pretty 1 -
• manually verifying the correctness of information displayed by ifconfig and ensuring that JSON/XML data works for all interface types

Some testing has already been done, here's are xml / json examples of the output so far: https://gist.github.com/paigeadelethompson/c69a78e2fa00b2d0a794fbbd1c595ff8

[paige_paige.bio]

I really just wanted to apologize in advance about the sheer size of this and I suspect it will need a few pair of eyes / a bit of testing and I've already tested a few including SFP info:

./ifconfig -vvvvv --libxo json | jq
...
        "sfp_id": "SFP/SFP+/SFP28",
        "sfp_physical_spec": "Unknown",
        "sfp_connector": "Copper pigtail",
        "sfp_vendor": "OEM",
        "sfp_part_number": "SFP-H10GB-CU0.5M",
        "sfp_serial": "210423022",
        "sfp_date": "2021-04-23",
        "sfp_dump": [
          3,
          4,
          33,
...

and I've done my best to in every case make sure that the text output is 1:1 with ifconfig pre-libxo every time that I've had to make changes, but I'd personally still like to make sure some things like CARP are correct (I don't have any CARP configurations off hand that I can test with)

EDIT:

Give me a day or so at least, and I will get a complete/official list of interfaces that are tested / confirmed to display correctly and send updates, Kurt also suggested potentially subscribing some related users (anybody who's also working on ifconfig or similar things like implementing libxo) I will try to get to this sooner rather than later. Adrian@ mentioned the desire to see some kind of regression testing for ifconfig output so that is probably something worth considering too.

As per my e-mail with Adrian he also said:

It's also an interesting deep dive into ifconfig to see what stuff in ifconfig should really be moved into libraries that do work (like what we're slowly doing with 802.11 stuff into its own library)

One that comes to mind immediately for me is the libifconfig library; I've looked at it many times and am always disappointed because short of vendoring it in your project you can't link against it because it's not installed to /usr/lib nor is there a static archive in /usr/lib; it's only linked against by ifconfig but also the scope of what it provides is rather limited. I don't know the story with it but it almost seems like an unfinished refactoring project that might have been lost to time (or maybe it does exactly what it needs to do and nothing else.) I gather you can install libifconfig from /usr/ports though, too and I'd guess maybe that has something to do with why it's not available via /usr/lib.

[paige_paige.bio]

I've found a couple of things on my own that I'd feel really dumb if I didn't speak up about now so I will just merely point out there's some really obvious formatting stuff, lack of comments on a couple of functions, I really just wanted to get some other folks looking at this before I step too deep. At this point I'm starting to weight the possibility of creating some ATF / unit tests against keeping the scope of this relatively contained. There's really a couple of things to consider about that

• There are a number of functions which start with print_ int the name that don't require a context (ctx) that also call xo_emit (easiest)
• There are also quite a few that do require a ctx because they're dealing with live interfaces, but they also in most cases substitute xo_emit for printf and it would probably be most beneficial if they were tested, but it would also in a lot of cases have to create a live interface before (harder)
• There's a lot of replacements for warn, err, etc for xo derivatives (xo_err, xo_warn etc), in a few places there are substitutions for perror commented /* perror */ that I need to fix function defined locally but asides from that mistake (which I will fix) all of the err / warn functions and errx/warnx seem to have equivalents and it's probably a waste of time to test those. (These didn't exist before for err/warn so may be not for this scope, if there's a reason to at all.)

I can't imagine anybody is really expecting tests for xo_err / xo errx / xo_warn / xo_warnx, other than the perror substitutions that I need to change back to perror (perror/perrorc just called errx/errc, so thats fine xo_errx and xo_errc.) I'm not looking forward to doing the harder ones, just because I'll have to code standing up the interface, testing the interface, tearing down the interface and its gonna be a bit but maybe it won't be so bad. I don't know what anybody is expecting but I'd personally prefer to tell you that's what I have in mind vs: bash -c 'diff -y <(/sbin/ifconfig) <(./ifconfig)' because lol I don't want to ship something that is going to break people's scripts and somebody say "oh well go figure there were no test cases." Let me see how hard it would be to come up with some ATF tests and see if we can easily address the possibility for regression, I'll follow up in a bit.