Thread (7 messages) 7 messages, 4 authors, 2017-02-27

Re: [PATCH 1/2] lightnvm: add generic ocssd detection

From: Sagi Grimberg <sagi@grimberg.me>
Date: 2017-02-27 19:45:06
Also in: linux-nvme, lkml

[adding linux-nvme to Cc as the patch changes the nvme driver, despite
the subject line]

On Sat, Feb 25, 2017 at 08:16:04PM +0100, Matias Bj=F8rling wrote:
quoted
On 02/25/2017 07:21 PM, Christoph Hellwig wrote:
quoted
On Fri, Feb 24, 2017 at 06:16:48PM +0100, Matias Bj=F8rling wrote:
quoted
More implementations of OCSSDs are becoming available. Adding each usi=
ng
quoted
quoted
quoted
pci ids are becoming a hassle. Instead, use a 16 byte string in the
vendor-specific area of the identification command to identify an
Open-Channel SSD.

The large string should make the collision probability with other
vendor-specific strings to be near nil.
No way in hell.  vs is vendor specific and we absolutely can't overload
it with any sort of meaning.  Get OCSSD support properly standardized a=
nd
quoted
quoted
add a class code for it.  Until then it's individual PCI IDs.
You are right, that is the right way to go, and we are working on it. In=
the
quoted
meantime, there are a couple of reasons I want to do a pragmatic solutio=
n:
Reasonable reaosons, but that's just not how standard interfaces work.
Either you standardize the behaviour and have a standardized trigger
for it, or it is vendor specific and needs to be keyed off a specific
vendor/device identification.
I agree, I don't see how we're allowed to use vs for that.

_______________________________________________
Linux-nvme mailing list
Linux-nvme@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-nvme
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help