> 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
