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. It might be good to add versioning info in the payload so we can extend results without breaking old binaries. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
