zpool: fix conflict with -v and -o options

[Shreshth3]

Fixes #11040.

Right now, the -v and -o options for zpool list work independently, but when paired, the -v "wins out" and the -o effect is lost. This commit fixes that problem.

Before my change:

(master) ~/zfs$ ./zpool list -v -o name,health mypool
NAME          HEALTH
mypool        ONLINE
  mirror-0   960M   110K   960M        -         -     2%  0.01%      -    ONLINE
    loop17     1G      -      -        -         -      -      -      -    ONLINE
    loop18     1G      -      -        -         -      -      -      -    ONLINE

After my change:

(v-o-option-conflict) ~/zfs$ ./zpool list -v -o name,health mypool
NAME          HEALTH
mypool        ONLINE
  mirror-0    ONLINE
    loop17    ONLINE
    loop18    ONLINE

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Quality assurance (non-breaking change which makes the code more robust against bugs)
• Breaking change (fix or feature that would cause existing functionality to change)
• Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the OpenZFS code style requirements.
• I have updated the documentation accordingly.
• I have read the contributing document.
• I have added tests to cover my changes.
• I have run the ZFS Test Suite with this change applied.
• All commit messages are properly formatted and contain Signed-off-by.

[robn]

Nice straightforward fix, good job!

[amotin]

Couldn't we make it more compact here and in other places? We do have 80 columns for last 30+ years. ;)

[Shreshth3]

Do you have any advice for a good setup to handle code formatting? I spent quite a bit of time trying to get a good setup, but haven't found anything that works well. I was going for format-on-save based a local .clang-format file. But with that setup, when I make my changes and save, it's re-formatting lines throughout the entire file.

Would be curious what you or any other maintainers do for code formatting. Thank you in advance!

[robn]

Unfortunately none of the code formatters around appear able to express the exact style, though some come very close. You should run make cstyle (or the script under it, scripts/cstyle.pl) as often as you can, which will definitely tell you when you've broken the "rules", such as they are.

For things like continuation line layout (the topic here), cstyle doesn't have a lot to say except that you get within 80 chars, and that your leading tabs and spaces look right. It won't care too much about where the lines are split and how many. Most people seem to just compress them into as few lines as possible; I usually try a few variations to balance concision with readability, but it can get pretty difficult sometimes.

This one, I would probably do:

			case ZPOOL_PROP_CAPACITY:
				cap = (vs->vs_space == 0) ?
				    0 : (vs->vs_alloc * 10000 / vs->vs_space);

I personally prefer to finish lines with an operator if I have the choice, and this is arguably readable as the possible outcomes are grouped together on the same line. If the computation had gone longer than 80, I probably would tried to at least avoid breaking the parens, and so made it more like:

			case ZPOOL_PROP_CAPACITY:
				cap = (vs->vs_space == 0) ? 0 :
				    (vs->vs_alloc * 10000 / vs->vs_space);

Sorry that's so vague; it's just what we've inherited. I'd would personally love to develop a (say) clang-format file that expresses most of what we have, and then we just take the defaults on the rest (in fact, I have developed most of this config a few times). The last bits though, that it doesn't support, needs a little thinking through and then someone to make the arguments and get the feedback and consensus and push it over the line.