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.
-- ljk
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm
