Re: [PATCH] lightnvm: move device L2P detection to core

[Javier Gonzalez]

> On 3 Aug 2018, at 14.43, Matias BjÃrling <mb@xxxxxxxxxxx> wrote:
> 
> On 08/03/2018 02:40 PM, Javier Gonzalez wrote:
>>> On 3 Aug 2018, at 14.37, Matias BjÃrling <mb@xxxxxxxxxxx> wrote:
>>> 
>>> On 08/03/2018 02:16 PM, Javier Gonzalez wrote:
>>>>> On 3 Aug 2018, at 10.54, Matias BjÃrling <mb@xxxxxxxxxxx> wrote:
>>>>> 
>>>>> A 1.2 device is able to manage the logical to physical mapping
>>>>> table internally or leave it to the host.
>>>>> 
>>>>> A target only supports one of those approaches, and therefore must
>>>>> check on initialization. Move this check to core to avoid each target
>>>>> implement the check.
>>>>> 
>>>>> Signed-off-by: Matias BjÃrling <mb@xxxxxxxxxxx>
>>>>> ---
>>>> I see where you want to go with these changes, but the way targets are
>>>> layered on top of the LightNVM subsystem does not align with it.
>>>> LightNVM can support different OCSSD versions and capabilities, but that
>>>> does not mean that a target (e.g., pblk) does. The way I see it, core
>>>> should only check for (i) the drive to expose itself in a known revision
>>>> and (ii) the reported structures to be consistent. However, specific
>>>> functionality is not for core to check upo.
>>> 
>>> Why try to initialize a target, if we already know that it is incompatible?
>> Yes, that is my point. But the one who knows if the targets supports
>> something or not is the target, not the subsystem. Here, you are making
>> an assumption knowing the pblk requires the L2P on the host, but that
>> could change in the future...
> 
> I don't believe it can. It is not supported by the 2.0 specification.
> 1.2 is legacy.
> 

Ja... We both know that people is using 1.2 variants out there...

> I understand this from the perspective when checking for un-even
> configurations using the geometry. But this is a spec incompatibility,
> which I don't think the target should care about.

I see the point of not having this check in pblk since we know that we
are moving towards 2.0 and leaving 1.2 as legacy/not-upstream. But does
it really make sense to fail LightNVM on a 1.2 capability that is spec.
compliant? For all we know people could have this and use it from user
space or through an internal target.

Javier

Attachment: signature.asc
Description: Message signed with OpenPGP