On Fri, Mar 31, 2017 at 12:43 PM, Linda Knippers <[email protected]> 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 [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
