Re: [RFC PATCH] Report the Health Status Detail for the HPE1 DSM family

[Dan Williams <dan.j.williams@intel.com>]

On Fri, Mar 31, 2017 at 12:43 PM, Linda Knippers <linda.knippers@hpe.com> wrote:
> Dan,
> This is an RFC because I'd like some initial feedback on the
> approach.  I think this is what you had in mind from your last
> exchanges with Brian but I wanted to check a few things before
> going too far.
>
> 1) Do we want to export a library function for what could be a long
> list of DSM-family-specific health information?  I think there
> could be some common information between the HPE1 and MSFT DSM
> but much will not be common.

Even for non-common information I want libndctl to hide the details
about which DIMM families support which fields. Just extend the
validity flags concept to make unsupported / family specific health
data appear as just an invalid field to the library interface if the
DIMM does not support it.

> 2) If we do export the functions, would we need to also export
> the ndctl-hpe1.h include file or consolidate the information into
> an already exported file?

I want to avoid libndctl ever exporting vendor-specific details. There
may be json keys that only show up on one vendor's DIMMs, but that
should be indistinguishable from a SMART payload that happens to clear
a validity bit.

> 3) Do you want json-smart.c to keep growing or should new smart
> functions provide their own matching json functions?

json-smart.c should understand the superset of all possible health
fields, i.e. the union of all vendor fields that can possibly be
returned. If this ever gets unwieldy it means we need to redouble
standardization efforts.

> 4) The code in json-smart.c with a macro was a quick prototype
> but if you have feedback on the json parts, that would be appreciated.
> Right now the detail is reported as a string if all is well and an
> array if there are errors.  I'm not sure about that or whether
> the strings should have spaces.

I think we should have all fields searchable as json keys in lowercase
with underscores. Lets handle these flags similar to the existing
boolean alarm_temperature and alarm_spares flags, but with a small
change. Since these flags are reporting some dimm-type-specific
details I think we should only add them to the json when they are
true. This way we won't have confusing entries like a
'"energy_source_error":false' line for non-energy-source-backed dimms.
I'll go back and fix up 'alarm_spares' and 'alarm_temperature' to be
hidden on DIMMs where they are always false.

Hmm, it seems like we need a "supported" vs "valid" distinction. Where
supported but invalid shows flags in the 'false' state, but
"unsupported" hides flags that are always going to be 'false'.
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm