[PATCH rfc 6/6] nvme-fabrics: expose support for traddr as dns names to userspace

[Daniel Wagner]

On Sun, Aug 20, 2023 at 01:55:47PM +0300, Sagi Grimberg wrote:
> > My gut feeling tells me in the long run it's good to have some generic
> > way to inform userspace of options format or feature changes. I am
> > pondering if sysfs wouldn't be the better place for this.
> 
> You would need a global entry for that, its not controller/subsystem
> specific. For that we have the misc device...

Ah, that explains why we have this interface after all.

> > ...,traddr=%s at v2,...
> > 
> > If I got this right, the current libnvme token parser would just ignore
> > the versioning string.
> 
> I don't think that this is a elegant option, there would need for some
> documentation entry for what is the versioning stuff. Plus, a
> feature/capability may not even relate directly to an existing token
> necessarily (if we generalize this).

I agree. It is clumsy.

> > Obviously, the simplest way is to introduce just a new token and be done
> > with it. I somewhat don't like it. Maybe I am trying to over engineer
> > this.
> 
> It could be a form of token that can emphasize its not a token like
> ",feat=<feat_name>" or "cap=<cap_name>"...
> 
> But this would definitely need to be done in a way that is compatible
> with userspace moving forward.

The libnvme parser is ignore anything it doesn't know yet. Introducing
'feat' or 'cap' is not a problem at all. Also it should be fairly simple
to add. The resulting code is likely to be very similar too; testing if
feat/cap or dns_ip_addr token is available and then use the dns name.

Given this, I am in favor of the feat/cap approach.