Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Better nvme capability detection (#129)
* utils/nvme: Parse nvme json output not human readable JSON + bit twiddling is more likely to be future compatible (hopefully). This library is not a human and thus should not use the human readable output. I would say that json + bit fiddling is also easier to understand than a regex based state machine. * utils/nvme: Use nvme cli internal names for capabilities These dynamic/generated names don't really work as can probably be noticed by adding the `fna` and `sanicap` synthetic capabilities. They don't work because nvme gives different output for enabled/disable, supported/unsupported, all/single capabilities. So we end up with enabled/disabled is detected by presence vs absence and we have to look up two "different" capabilities to determine the status of an _actual_ capability. So instead of doing that dynamic name we just use the internal nvme identifiers seen in `nvme-print-stdout.c` at this point in time. We will not change them later if nvme changes them internally. This way we end up being more likely to be future proof. It would be much easier for nvme-cli to tweak the string returned in the human readable output than it would be for the linux kernel to change meaning of bits returned in the ioctl call. * utils/nvme: Get rid of fake nvme capabilities fna and sanicap These don't really tell much to callers, considering we have a better breakdown of what fna and sanicap mean so lets just drop it. * utils/nvme: Explicitly test parsing fna and sanicap values Better to test explicitly for all expected cases than implicitly/by proxy from the other tests.
- Loading branch information