On Thu, Jul 28, 2016 at 11:46 AM, Linda Knippers <[email protected]> wrote: > > > On 7/28/2016 2:20 PM, Dan Williams wrote: >> On Thu, Jul 28, 2016 at 10:43 AM, Linda Knippers <[email protected]> >> wrote: >>> >>> >>> On 7/28/2016 5:45 AM, Johannes Thumshirn wrote: >>>> On Wed, Jul 27, 2016 at 02:23:51PM -0400, Linda Knippers wrote: >>>>> Hi Johannes, >>>>> >>>>> I hope Dan and Jerry also reply but I have recently started looking at >>>>> this too and have some comments below. >>>> >>>> So if we two are looking into it we might want to work together so we >>>> don't do >>>> all the work twice. >>> >>> Definitely! >>> >>>> I've pasted my current work to export HPE DIMM commands at the bottom of >>>> the >>>> mail, but I don't like it very much (see below for a proposal of a more >>>> elegant way). >>>> >>>>> >>>>> On 7/27/2016 6:35 AM, Johannes Thumshirn wrote: >>>>>> Hi Dan and Jerry, >>>>>> >>>>>> I'm currently looking into SMART data retrieval on HPE NVDIMMs. >>>>>> >>>>>> After the first obstacle (like getting cat >>>>>> /sys/class/nd/ndctl0/device/nmem0/commands reutrn smart so ndctl will >>>>>> issue >>>>>> the ioctl) I ran into a rather nasty problem. According to [1] HPEDIMMs >>>>>> need the input buffer specially crafted for SMART data, according to [2] >>>>>> Intel DIMMs don't. >>>>> >>>>> It is unfortunate that the DSM functions are different for different >>>>> NVDIMM >>>>> >>>>> types. There is a desire for standardization but for now this is what we >>>>> have. >>>> >>>> Sure, let's see what we can come up with to "fix" the situation. >>>> >>>> I had a quick chat here internally at SUSE and one suggestion was to create >>>> something, let's call it "filter drivers", to support different DSMs for >>>> different NVDIMM families. I actually like the idea and if no-one objects >>>> I'll >>>> try to implement some kind of prototype for the "filter drivers". >>> >>> I think a question we need to answer is what should be in the kernel vs. in >>> user >>> space and what the interface between the two should look like. The kernel >>> doesn't necessarily need to know that function 1 returns health information >>> and function 2 returns threshold information unless it needs the information >>> itself. I think the intent of cmd_call was just as a pass-through mechanism >>> to keep from adding more code into the kernel. We could create ndctl >>> functions >>> instead. I know this is different from how the original Intel DSM functions >>> are implemented but that could be considered legacy code to support existing >>> applications at this point. >>> >>> For history, the first discussions about this approach were on the nvdimm >>> list back in November and it went from there. >>> https://lists.01.org/pipermail/linux-nvdimm/2015-November/002721.html >>> >> >> To me, the cmd_call mechanism is useful for commands that libnvdimm >> does not and may never care about. For the generally useful commands >> that the kernel needs to be involved with I'd like to define a common >> kernel command set and do in-kernel translation across the >> different-for-difference sake implementations. > > I don't think any of them are different-for-different sake. > > No one has time for busy work. > > > > It takes a lot of work and collaboration to standardize these things > > and so far, we're still not even through the potential root device functions. > > Standardizing functions across different device types with different > > characteristics is even harder.
I understand that it is hard, we are where we are due to expediency, and Linux now supports all the known first generation command sets. The "different for difference sake" comment was made with my Linux hat on where I see the kernel supporting the _INTEL and _HPE2 command sets which are frustratingly similar. Linux has always been a vehicle for discovering and refactoring commonality across vendors. We can use a common Linux command format to inform the standardization discussion going forward. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
