Skip to content

nvme-cli/fabrics: consume the INI config directly from the CLI#3595

Open
martin-belanger wants to merge 2 commits into
linux-nvme:masterfrom
martin-belanger:libnvme-config-apply-params
Open

nvme-cli/fabrics: consume the INI config directly from the CLI#3595
martin-belanger wants to merge 2 commits into
linux-nvme:masterfrom
martin-belanger:libnvme-config-apply-params

Conversation

@martin-belanger

Copy link
Copy Markdown

Summary

  • Add libnvmf_context_apply_params(), a table-driven helper that applies a resolved parameter set (from INI) to a connect context (fctx).
  • Switch connect-all/discover/connect -J to read the INI configuration directly and iterate connections in the CLI itself, instead of going through libnvme's JSON config loops. Hostname resolution and hostnqn/hostid selection are policy decisions and now live in the CLI. The CLI enforces the exclusion list on every auto-connected entry.
  • Old style config (config.json, discovery.conf) automatically converted to INI on first invocation.
  • Retire the /run/nvme volatile-config reader and the discovery.conf line-parser hooks: nothing reads the former, and the INI config replaces the latter's only caller.

First slice of moving nvme-cli off the legacy JSON config path onto the INI config from #3566/#3587/#3590/#3591. Self-contained: -O/--dump-config, nvme config's -M/-R/-U, and the now-unused JSON loops in libnvme are untouched here, addressed in follow-up PRs.

Test plan

  • meson test -C .build — 86/86 passing
  • make checkpatch — 0 errors
  • Each commit builds standalone
  • Manual: nvme connect -J <ini-file>, nvme discover, nvme connect-all against scratch INI configs (default path, custom -J, legacy-JSON auto-convert), under valgrind — no leaks

Martin Belanger added 2 commits July 20, 2026 10:27
Add libnvmf_context_apply_params() to set an fctx from the params
read from an INI file. An unset key is left alone, and an explicit
reset (the empty string) is skipped rather than applied as zero.

Signed-off-by: Martin Belanger <martin.belanger@dell.com>
connect-all, discover, and connect -J now consume the INI config
directly. Looping over each INI entry is performed by the CLI itself,
so hostnames can be resolved (a policy decision) before calling into
libnvme. Choosing hostnqn/hostid is likewise a policy decision, so
that also stays in the CLI rather than libnvme. The CLI also honors
the exclusion list to prevent unwanted connections.

Retire the /run/nvme volatile-config reader and the discovery.conf
line-parser hooks: nothing reads the former, and the INI config
replaces the latter's sole caller.

Signed-off-by: Martin Belanger <martin.belanger@dell.com>
Comment thread libnvme/src/nvme/config.c
else if (!strcmp(key, "keep-alive-tmo"))
/* Applied verbatim; the NQN-conditional default is a
* connect-time decision, see set_discovery_kato().
*/

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'this comment doesn't make sense to me this is KATO who does the nqn play a role?

Comment thread libnvme/src/nvme/config.c
}
/* Identity/addressing keys never reach here: get_params() only
* surfaces tunable and security keys.
*/

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand the first part of the comment, the second part is what? this is apply_params?

Comment thread libnvme/src/nvme/config.c
return;

/* strtol(..., 0) matches check_int()'s hex/octal-aware parsing
* (config-ini.c); atoi() would mis-parse "0x10" as 0.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no need to add man page documentation on strtol.

Comment thread libnvme/src/nvme/config.c
const char *ctrlkey;
const char *keyring;
const char *tls_key;
const char *tls_key_identity;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

libnvmf_context has

	const char *hostkey;          // !access:write=custom
	const char *ctrlkey;          // !access:write=custom
	const char *keyring;          // !access:write=custom
	char *tls_key;                // !access:write=custom
	const char *tls_key_identity; // !access:write=custom

Why do we need to treat them special. The comment mentiones 'clobbering' how? There is nothing special about these keys, we can either pass them via the connect string or we load them into the kernel keystore.

Comment thread libnvme/src/nvme/config.c

/* An explicit reset is not applied: @fctx already carries the
* kernel default it was created with (libnvmf_default_config()).
*/

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but only two keys have defaults

void libnvmf_default_config(struct libnvme_fabrics_config *cfg)
{
	cfg->tos = -1;
	cfg->ctrl_loss_tmo = NVMF_DEF_CTRL_LOSS_TMO;
}

what about the rest? and these are not kernel defaults. these are library defaults.

@igaw

igaw commented Jul 21, 2026

Copy link
Copy Markdown
Collaborator

For the first commit could you update the commit message. It's really hard to read. Maybe

libnvme/config: apply a parameter store to a connect context

Add libnvmf_context_apply_params() to apply the parameters read from an
INI file to an fctx. Parameters corresponding to unset keys are left
unchanged, while parameters explicitly reset to the empty string are
skipped instead of being applied as zero.

?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants