nvme id-ns: neglect empty vendor-specific fields

[itscool900]

The nvme id-ns command accepts -V for vendor-specific fields. However, I'm fairly sure that it is common for said fields to be empty. Thus it would not make sense to show them with no further explanation.
Thus, I propose that, especially in the human-readable format, nvme id-ns, when run with the -V option, should hide the vendor-specific field and/or report that it is empty.

Thanks for your consideration.

[igaw]

In stdout_id_ctrl we have:

static void stdout_id_ctrl(struct nvme_id_ctrl *ctrl,
			   void (*vendor_show)(__u8 *vs, struct json_object *root))
{
	bool human = stdout_print_ops.flags & VERBOSE, vs = stdout_print_ops.flags & VS;

[...]

	if (vendor_show)
		vendor_show(ctrl->vs, NULL);
	else if (vs) {
		printf("vs[]:\n");
		d(ctrl->vs, sizeof(ctrl->vs), 16, 1);
	}

Not sure if I understand your request correctly, especially the interaction with with the --verbose flag.

(--human-readable is deprecated, we added --verbose to all commands so it is more consistent, the code needs some more cleanup as you can see above, the flag should be called verbose and not human anymore.)

Anyway, when the -V option is used (and we don't use a plugin), the command will print the vendor specific fields. This seems to be the correct behavior to me. The user is asking for it, thus we print it even if it is all zeros. As this field is vendor specific I don't know what we could/should do with the verbose flag here.

[ikegami-t]

As mentioned currently all zero data are repeated as below.

tokunori@tokunori-X570-Taichi:~/nvme-cli$ nvme-build id-ns /dev/nvme0n1 -V 
NVME Identify Namespace 1:
nsze    : 0x5000
...
eui64   : 0000000000000000
lbaf  0 : ms:0   lbads:9  rp:0 (in use)
lbaf  1 : ms:0   lbads:12 rp:0 
vs[]:
       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................"
... (Repeated all zero data)
0e70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................"

By the way the hexdump command outputs * as below instead of the zero data repeated.

tokunori@tokunori-X570-Taichi:~/nvme-cli$ hexdump data2.bin -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000060
tokunori@tokunori-X570-Taichi:~/nvme-cli$ ls -la data2.bin
-rwxr--r--+ 1 tokunori tokunori 96 Jan  6 00:22 data2.bin

So we can change as below for the human readable option -H I think. How about this?

tokunori@tokunori-X570-Taichi:~/nvme-cli$ nvme-build id-ns /dev/nvme0n1 -V -H
NVME Identify Namespace 1:
nsze    : 0x5000
...
eui64   : 0000000000000000
lbaf  0 : ms:0   lbads:9  rp:0 (in use)
lbaf  1 : ms:0   lbads:12 rp:0 
vs[]:
       0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
0000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 "................"
*
0e80:

[itscool900]

I like ikegami's idea--with the qualification that this behavior is documented in the manpage.

As far as 'correct behavior', I am suggesting that we change the standard for the sake of accessibility--it's much easier to understand the output if the program directly tells the user that the vendor-specific field was neglected. (I do not see another possible interpretation.)

Also, could you point me to where in the docs it says that the -H option is deprecated, if at all? (Mostly asking because the ArchWiki endorses it, and I would like to fix that if it's out of date.)

[igaw]

Sure, making the output a bit smarter and not printing all the zeros sounds like a good idea. No objection from me.

We introduced --verbose/-v for every single command and now we have some commands which also have --human/-H.
--human is 100% equal to --verbose. But -v has a trick up it sleeves, if you do a -vv it enables the debug verbosity level.

I don't think we haven't updated the man pages that the --human is considered deprecated and replaced by --verbose. IIRC, it was only documented in the git commit message... Any takers?

[ikegami-t]

The verbose option was changed by the commit: 5cbfb18 as same with the human-readable option.

(Added)
Yes I also think the human-readable option is not depreciated (but duplicated with the verbose option as mentioned..).