On 2/16/2017 5:43 PM, Dan Williams wrote:
On Thu, Feb 16, 2017 at 2:40 PM, Linda Knippers <[email protected]> wrote:
On 2/16/2017 4:07 PM, Dan Williams wrote:
On Thu, Feb 16, 2017 at 12:48 PM, Dan Williams <[email protected]>
wrote:
On Thu, Feb 16, 2017 at 12:13 PM, Linda Knippers <[email protected]>
wrote:
[..]
I am fairly certain that for production use we wouldn't expect
management
tools to use more than one DSM family at a time. Tools using DSMs
from one family wouldn't switch to using a new family for one operation
and then switch back for another operation.
If the kernel makes it safe I don't see why this is a blocker,
especially if the goal is to reduce interface proliferation over time.
In fact, we can make it even simpler than dynamically changing family,
just have ND_IOCTL_VENDOR always route to uuid
""4309ac30-0d11-11e4-9191-0800200c9a66" and function number 9. Then
that becomes the de facto method for Linux to issue a vendor-specific
command for any DIMM.
Several problems.
That family is documented for RFIC 0x0201.
No NVDIMM-N platform supports that DSM family.
When platforms do support 0x0201, some will also support NVDIMM-N. Since
opcodes are not documented, how do would they not step on each other?
I don't think that works at all.
I'm confused there is no correlation between FIC and DSM family,
Page 7 of version 1.3 of your DSM spec says:
Platforms that have the _DSM interface implemented, as outlined in this section,
can support a NVDIMM region with Region Format Interface Code (RFIC) of 0x0201.
Other DSM documents reference RFIC 0x0101.
at least not one Linux enforces.
That is true, but FW developers aren't being as loose.
-- ljk
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm
