Repository navigation
Conversation
The JSON printer always decoded the telemetry log page header with the Host-Initiated layout, so a Controller-Initiated log reported reserved byte 380 as the Host-Initiated Scope and labelled bytes 381-382 as host fields. The text printer chose the layout from --telemetry-type, which could also mislabel a log file whose type differed from that option. Choose the header layout from the Log Identifier of the log (byte 0). The mock suite now checks the controller header in JSON and that the layout follows the Log Identifier. Signed-off-by: Broc Going <bgoing@micron.com>
Several telemetry log page header fields were decoded under names that do not match the NVMe Base Specification: - the Controller-Initiated log's Data Area 1-4 Last Block fields were labelled as Telemetry Host-Initiated fields; - byte 381 of the Host-Initiated log was labelled "Telemetry Host Initiated Generation Number" instead of "Telemetry Host-Initiated Data Generation Number"; - byte 382 of the Host-Initiated log was labelled "Telemetry Host-Initiated Data Available", but it is the Telemetry Controller-Initiated Data Available field copied from the Controller-Initiated log. Use the spec names in both output formats. This changes the affected JSON keys. Signed-off-by: Broc Going <bgoing@micron.com>
|
With this change can |
When telemetry-log is provided, determine the telmetry type from the LID of the provided log. This makes telemetry-type optional. Ensure that if telemetry-type is provided as well, the type matches the type detected from the provided log. Move controller-initiated support check into the telemetry fetching path where it is needed, and report an error if a controller-initiated log is requested but is not supported. Also fix error reporting for similar data area 4 support check. Signed-off-by: Broc Going <bgoing@micron.com>
An invalid --data-area value printed an error, but internal-log still exited with status 0. Return -EINVAL instead. Signed-off-by: Broc Going <bgoing@micron.com>
Yes. I was planning on that as a next step. I've added it to this PR instead. When --telemetry-log is used, telemetry type is now completely determined by the log identifier in the supplied log. --telemetry-type is not required when using --telemetry-log. It is ignored if it matches the detected log type, but the command will now report an error if --telemetry-type is specified but doesn't match the detected log type. Let me know if you have any feedback on the updated behavior. Thanks. |
The doc string for ocp internal-log --telemetry-type changed. Update the completion file to match. Signed-off-by: Broc Going <bgoing@micron.com>
|
Thanks! |
The JSON printer always decoded the telemetry log page header with the Host-Initiated layout, so a Controller-Initiated log reported reserved byte 380 as the Host-Initiated Scope and labelled bytes 381-382 as host fields. The text printer chose the layout from --telemetry-type, which could also mislabel a log file whose type differed from that option. Several telemetry log page header fields were also decoded under names that do not match the NVMe Base Specification
-t.Updates the mock coverage in
tests/cli/ocp/ocp_internal_log_mock_test.py.