lkml.org 
[lkml]   [2018]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] lightnvm: move device L2P detection to core
Date
> On 3 Aug 2018, at 14.43, Matias Bjørling <mb@lightnvm.io> wrote:
>
> On 08/03/2018 02:40 PM, Javier Gonzalez wrote:
>>> On 3 Aug 2018, at 14.37, Matias Bjørling <mb@lightnvm.io> wrote:
>>>
>>> On 08/03/2018 02:16 PM, Javier Gonzalez wrote:
>>>>> On 3 Aug 2018, at 10.54, Matias Bjørling <mb@lightnvm.io> 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@lightnvm.io>
>>>>> ---
>>>> 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
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2018-08-03 14:56    [W:0.083 / U:0.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site