On Thu, Jul 28, 2016 at 10:43 AM, Linda Knippers <linda.knippers(a)hpe.com> 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.
> 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  HPEDIMMs
>>> need the input buffer specially crafted for SMART data, according to 
>>> 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
> 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.
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.