On Thu, Sep 07, 2017 at 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.