[PATCH] nvme: fix lightnvm check

[hch@lst.de (Christoph Hellwig)]

On Thu, Sep 07, 2017@02:15:52PM +0200, Matias Bj?rling wrote:
> I must have misunderstood when we discussed it. I understood it as to add 
> detection to the NVMe specification.
>
> Going with Class code might not be the right way due to them describing the 
> base protocol.

Well - existing NVMe (except Linux with lighnvm) simply expect a NVMe
PCIe device to support the NVM I/O command set.  So if you have a drive
that wants to speak a different one it needs to be bindable to a new
driver and thus have a different PCIe class code.

But even with that in place we should also have the new command set
in CAP - so that a common code base can work all these devices, and
the command set can be used over fabrics as well for example.

> bit. Another approach, as OCSSD has grown, might be to use the existing 
> command set, and teach the identify command about Zones/Chunks, where one 
> writes sequentially within.

Even then we need a way to identify such devices.  SCSI is a great
example - if the device has zones that MUST be written sequentially
it's a new ZBC device type.  If the device just wants zones to be
written sequentially but can handle random writes with a performance
penalty it's the good old SBC type with a few extensions.