[PATCH 3/3] nvmet: include all configured ports in discovery log page for unique discover controller
Sagi Grimberg
sagi at grimberg.me
Tue Apr 5 07:22:51 PDT 2022
>>>>> To make it configurable.
>>>>> Unique discovery controllers show up in configfs just like any other
>>>>> subsystems.
>>>>> And with that we need to clarify the relationship between the
>>>>> discovery
>>>>> subsystem and the other subsystems, ie which subsystems should be
>>>>> presented
>>>>> by this discovery subsystem.
>>>>>
>>>>> Linking the discovery subsystem into a given port makes it obvious
>>>>> that
>>>>> a) this port will be presenting a discovery subsystem
>>>>> and
>>>>> b) that the discovery subsystem will be presenting all subsystems
>>>>> configured on that port.
>>>>>
>>>>> The built-in mechanism for discovery subsystems was okay as long as
>>>>> the
>>>>> discovery subsystem was built-in, too.
>>>>> But with this patchset we're moving to an explicit configuration.
>>>>
>>>> Shouldn't we just require anything to be manually listed for this
>>>> case similar to how we configure referrals for the well known
>>>> discovery controller?
>>>
>>> Which is what I've tried with this attempt.
>>> I did _not_ want to create a new configuration mechanism, but rather
>>> use the existing ones.
>>> And the existing mechanism we have is linking subsystems to ports.
>>>
>>> If we want to treat discovery subsystems differently (as you
>>> proposed) we sure can have a different mechanism on how to configure it.
>>> But I wasn't sure if that's the direction we want to go.
>>
>> What is the concern here? that it will break existing users with
>> introducing an additional configuration step?
>
> Yes. It would break backward compability.
So maybe hide it behind a modparam that we can deprecate in the future?
More information about the Linux-nvme
mailing list