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, at least not one Linux enforces. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
