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

[Sagi Grimberg]

>> Where do you stand on the kernel exposing capabilities that do not
>> manifest in "valid tokens" when writing to /dev/nvme-fabrics ?
>>
>> today when we read /dev/nvme-fabrics we get a string with all
>> the valid tokens. that is useful for userspace to understand what
>> it can or cannot pass in a fabrics connection string.
>>
>> In the example here, we are trying to introduce a new format for
>> traddr argument that is now supported by the fabrics driver (tcp/rdma)
>> where traddr can now be ipv4, ipv6 or a dns name (where before this
>> patchset it could only be ipv4 or ipv6).
>>
>> The question is:
>> Do we enforce that every new capability must come with a matching valid
>> token? Or do we want to expose capabilities that are not necessarily
>> come with dedicated tokens (like in this example)?
>>
>> I think the latter is a be better approach. But could be convinced
>> otherwise...
> 
> 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...

> But then we
> would need to gather this info from two places. Not nice.
> 
> Just to through in another idea, we could also introduce a version
> scheme, e.g.
> 
> ...,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).

> 
> 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.