Initial parsable output flags for xcvradm

[augustuswm]

This PR adds new flags to the "read" commands of xcvradm. The pattern is as followings:

• -p --parsable - Flag to toggle outputting in parsable format
• -o --output - List of comma fields to output. Fields will be output in the order defined, with repeated values allowed.
• --output-separator - Separator used to delineate field values.

There is still no flag for omitting headers that needs to be added.

This PR should not change the default behavior of any commands.

[augustuswm]

Example output of a vendor-info call:

BRM42220047-switch # ./xcvradm --interface sidecar0 -E vendor-info -p -o port -o vendor -o port -o rev -o part -o serial -o manufactured-date --output-separator ':::' --omit-header
1:::Intel Corp:::1:::03:::SPTSMP3CLCDA:::CRFR21400F6HP:::21101300
2:::Intel Corp:::2:::03:::SPTSMP3CLCDA:::CRFR21400CTKP:::21101300
3:::Intel Corp:::3:::03:::SPTSMP3CLCDA:::CRFR21400DVBP:::21101900
4:::Intel Corp:::4:::02:::SPTSMP3CLCAD:::CRFR22164H14P:::23081600
5:::Intel Corp:::5:::02:::SPTSMP3CLCAD:::CRFR2210010WP:::23081600
6:::Intel Corp:::6:::03:::SPTSMP3CLCDA:::CRFR21400APBP:::21101800
7:::Intel Corp:::7:::03:::SPTSMP3CLCDA:::CRFR2140093KP:::21101900
8:::FINISAR CORP.:::8:::A0:::FTCC8612E2PCM:::XAGAEWK:::240309
9:::FINISAR CORP.:::9:::A0:::FTCC8612E2PCM:::XA2BES0:::240306
10:::FINISAR CORP.:::10:::A0:::FTCC8612E2PCM:::XB8AR7E:::240410
11:::FINISAR CORP.:::11:::A0:::FTCC8612E2PCM:::XB8AR9Z:::240410
12:::FINISAR CORP.:::12:::A0:::FTCC8612E2PCM:::XB8ARGL:::240410
13:::FINISAR CORP.:::13:::A0:::FTCC8612E2PCM:::XB8ARJP:::240410
14:::FINISAR CORP.:::14:::A0:::FTCC8612E2PCM:::XB8ARKZ:::240410
15:::FINISAR CORP.:::15:::A0:::FTCC8612E2PCM:::XAGAEWM:::240318
16:::Intel Corp:::16:::03:::SPTSMP3CLCDA:::CRFR21400HBJP:::21101600
17:::Intel Corp:::17:::03:::SPTSMP3CLCDA:::CRFR214101WKP:::21101400
18:::Intel Corp:::18:::03:::SPTSMP3CLCDA:::CRFR21400F9JP:::21101300
19:::Intel Corp:::19:::03:::SPTSMP3CLCDA:::CRFR21400DNFP:::21101500
20:::Intel Corp:::20:::03:::SPTSMP3CLCDA:::CRFR213908ADP:::21101200
21:::Intel Corp:::21:::03:::SPTSMP3CLCDA:::CRFR21400A2RP:::21101500
22:::Intel Corp:::22:::03:::SPTSMP3CLCDA:::CRFR214102RGP:::21101600
23:::Intel Corp:::23:::03:::SPTSMP3CLCDA:::CRFR21400ELCP:::21101900
24:::FINISAR CORP.:::24:::A0:::FTCC8612E2PCM:::XAGAEWW:::240309
25:::FINISAR CORP.:::25:::A0:::FTCC8612E2PCM:::XB8ARAW:::240410
26:::FINISAR CORP.:::26:::A0:::FTCC8612E2PCM:::XB8ARB8:::240410
27:::FINISAR CORP.:::27:::A0:::FTCC8612E2PCM:::XB8ARJ8:::240410
28:::FINISAR CORP.:::28:::A0:::FTCC8612E2PCM:::XAGAEY7:::240309
29:::FINISAR CORP.:::29:::A0:::FTCC8612E2PCM:::XB8ARN6:::240410
30:::FINISAR CORP.:::30:::A0:::FTCC8612E2PCM:::XAGAEZG:::240318
31:::FINISAR CORP.:::31:::A0:::FTCC8612E2PCM:::XB8ARJQ:::240410

[bnaecker]

This is awesome, great work. I have a few small suggestions, but it mostly looks good to me. Thanks!

[bnaecker]

I think we may want an empty string here instead of "unsupported". That would make it easier for a program parsing this output to distinguish "there was no temperature / voltage / power to parse" from "I failed to parse this as a decimal value".

Whatever we decide, I think it'd be useful to put in the CLI --help output what value these take if they're not supported. Module support for these varies widely, so it'll definitely be something we need to make clear how to handle in a parsing program.

[augustuswm]

Agreed, I like having an empty string for cases where we do not have a value to report. I updated the help message to include the distinction:

Usage: xcvradm --interface <INTERFACE> monitors [OPTIONS]

Options:
  -p, --parseable
          Print the output in a parseable format

  -o, --output <OUTPUT>
          Select the output fields to be displayed. Fields that are not supported by a module are emitted as empty values

          Possible values:
          - port:             The port number of the switch
          - temperature:      The temperature of the transceiver module
          - supply-voltage:   Voltage supplied to the transceiver module in V
          - average-rx-power: Average received power of the transceiver module in mW
          - tx-bias:          Transmit bias current of the transceiver module in mA
          - tx-power:         Transmit power of the transceiver module in mW
          - aux1:             Auxiliary monitor 1 as reported by the transceiver module
          - aux2:             Auxiliary monitor 2 as reported by the transceiver module
          - aux3:             Auxiliary monitor 3 as reported by the transceiver module

      --output-separator <OUTPUT_SEPARATOR>
          Character used to separate output fields. (Default: ":")

      --omit-header
          Omit displaying the output header

  -h, --help
          Print help (see a summary with '-h')

What I am not sure about though is how to handle invalid or unexpected values. We aren't really validating values that this point though, so it is really an "is there a value or not" case.

[bnaecker]

What I am not sure about though is how to handle invalid or unexpected values. We aren't really validating values that this point though, so it is really an "is there a value or not" case.

I think that's right. If we get to the point of having, say, the supply voltage, then it's "valid" by definition. We don't do any sort of sanity or range checking on that. Assuming we can read the bits from the transceiver in the first place, we only do a scaling and then return the value.

Is that what you meant?

[augustuswm]

Got it. Ok, that makes sense, and tracks with how I understood what we are doing. I think the "empty" or "value" here makes sense then.