humility ringbuf should have parseable output

[jclulow]

The humility ringbuf command prints a log of essentially human-readable ring buffer records; e.g.,

humility: ring buffer drv_gimlet_seq_server::__RINGBUF in gimlet_seq:
 NDX LINE      GEN    COUNT PAYLOAD
  13 1222        1        1 V3P3SysA0VOut(Volts(0.15234375))
  14  373        1        1 A2
  15  535        1        1 SpdDimmsFound(0x10)
  16  648        1        1 SetState(A2, A0, 0x710)
  17 1222        1        1 V3P3SysA0VOut(Volts(0.06640625))
  18  652        1        1 PGStatus { b_pg: 0x0, c_pg: 0x0, nic: 0x0 }
...

Sometimes we want to perform programmatic analysis on the ring buffer contents of a dump or live system. It would help to have a machine-readable version of this data. It could look something like this:

[
    {
        "task": "gimlet_seq",
        "name": "drv_gimlet_seq_server::__RINGBUF",
        "entries": [
             { "ndx": 13, "line": 1222, "gen": 1, "count": 1,
               "payload": {
                   "t": "V3P3SysA0VOut",
                   "v": {
                       "t": "Volts",
                       "v": 0.15234375
                   }
               }
             },
             { "ndx": 14, "line": 373, "gen": 1, "count": 1,
               "payload": {
                   "v": "A2"
               }
             }
        ]
    },
    {
        "task": "power",
        "name": "drv_i2c_devices::adm1272::__RINGBUF",
        "entries": [
            { "ndx": 0, "line": 106, "gen": 1, "count": 1,
              "payload": {
                 "t": "Config",
                 "v": {
                    "t": "CommandData",
                    "v": 16183
                 }
              }
            },
            { "ndx": 0, "line": 106, "gen": 1, "count": 1,
              "payload": {
                 "t": "WriteConfig",
                 "v": {
                    "t": "CommandData",
                    "v": 16191
                 }
              }
            }
        ]
    }
]

There are some more complex values in other ring buffers; e.g., Rx(UdpMetadata { addr: Ipv6(Ipv6Address([ 0xfe, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xaa, 0x40, 0x25, 0xff, 0xfe, 0x5, 0x26, 0x2 ])), port: 0xffd8, size: 0xa, vid: 0x302 }). I think it should, hopefully, still be easy enough to render these in some regular JSON form; e.g.,

{
    "t": "Rx",
    "v": {
        "t": "UdpMetadata",
        "v": {
            "addr": {
                "t": "Ipv6",
                "v": {
                    "t": "Ipv6Address",
                    "v": [ 254, 128, 0, 0, 0, 0, 0, 0,
                           170, 64, 37, 255, 254, 5, 38, 2 ]
                }
            },
            "port": 65496,
            "size": 10,
            "vid": 770
        }
    }
}

You could imagine also having some basic improved formats for things we can easily render like IPv6 addresses; e.g.,

{
    "t": "Rx",
    "v": {
        "t": "UdpMetadata",
        "v": {
            "addr": "fe80::aa40:25ff:fe05:2602",
            "port": 65496,
            "size": 10,
            "vid": 770
        }
    }
}

[cbiffle]

Noticed this when filing another bug -- just want to note that programs parsing ringbuf output are liable to be broken by updates, since nothing about the contents of ringbufs are stable. As long as they accept that risk, we're okay. (This is not about the Humility output per se, but rather the things put in the ringbufs.)

[jclulow]

Yes, definitely understand that we'd have to be aware of the specific software version when consuming this data. I'd like to have a Committed set of flags and parseable output for inspecting the data from debugging and diagnostic tools, with the knowledge that the presented data is firmly Uncommitted.