It seems a little odd to include the leading whitespace that (?)all subcommands will have, instead of doing it generally in whatever processes the linkerset for usage (I'm reading this top to bottom for now, haven't gotten to that part).

I guess it makes sense if you need multi-line usage strings for a complicated subcommand, and don't want to do something clever, like check for newlines in the generic usage routine.

(Edit after reading the rest of the patch: Especially given this is the status quo — we're just moving the strings around here — abstracting out the indentation is something that can be left for a future cleanup patch.)

If we wanted to be more clever about indentation, it would go somewhere around here.

We should probably return after finding a match to avoid printing "Unknown command" when we found a command

It looks like this is unused for now, aside from NVME_COMMAND directly below. Given that, is there any reason to define it instead of just using DATA_SET directly in NVME_COMMAND?

name ## _nvme_cmd makes more sense to me, but function isn't very objectionable to me, if you prefer to keep it as-is.

I'd prefer the C99 designated initializer form:

{
  .name = #name,
  .fn = function,
  .usage = usage,
}

(That might require changing the macro parameter name to something else, but that's ok.)

I'd suggest const nvme_function * const * for the pointers, given we shouldn't mutate the pointer table nor the objects as part of dispatch.

(The "\t" here doesn't match the style of other usage indentation.)

Correct, this is just code movement.

Right, it's kinda hard given the continuation stuff that's there now. It would require some careful thought.

Today, all those functions exit, so I'll consider this for a future cleanup.

(a) it's logical and (b) I may tweak the set name when I introduce the logfile sets.

name is the user command, function is the function we call. There are some user commands with hyphens, so I need two parameters.

Meh. I prefer shorter to longer... I'm not sure this adds any value, but I'll think about it.

const foo * const * is a pain in the ass to use. And I think that the set marcros make that a pain to use since they don't have enough consts sprinkled in. So I'll give it a shot, but punt if the PITA factor pops up.

I'll do a separate fix and fix that when I do the indentation fix. This is just code movement.

It is painful, so I'm not going to do it. I tried a few different variations and punted.

yea, doesn't matter since it just needs to be unique, but hobgoblins and all

I'll do that.

No, things are lined up so it doesn't need that.

Not in this change, but maybe in the future.

True ;; is harmless, but I'll fix.

true, I'll fix this, even though that's supposed to just be code movement.