> As mentioned above this function seems to assume that the only DIMM events to > send are DIMM health events. It's ok to save other object monitoring to a > later patch, > but let's at least support DIMM health > events: > > dimm-spares-remaining > dimm-media-temperature > dimm-controller-temperature > dimm-health-state > > ...and DIMM detected events: > > dimm-unclean-shutdown > dimm-detected > > There should be an event type included in the json. Along with 'timestamp' > and 'pid' > I think we need an 'event' field so that consumer code can make assumptions > about > the format of the event record. I think 'dimm-health' and 'dimm-detect' are > the only > event record types we need to support in this initial version. >
Hi, Dan I would like to confirm whether my understanding of the feature in each dimm-event is right or not. a) dimm-spares-remaining Checking the Spare Block Remaining Trip in Alarm Trips, if set then the notification is dimm-spares-remaining. b) dimm-media-temperature Checking the NVDIMM Media Temperature Trip in Alarm Trips, if set then the notification is dimm-media-temperature. c) dimm-controller-temperature Checking the NVDIMM Controller Temperature Trip in Alarm Trips, if set then the notification is dimm-controller-temperature. d) dimm-health-state Checking the Health Status, if changed then the notification is dimm-health-state. e) dimm-unclean-shutdown Checking the Last Shutdown Status, if changed then the notification is dimm-unclean-shutdown. f) dimm-detected Checking the UUID of DIMM, if changed then the notification is dimm-detected. Is there a possibility that a notification contains multiple dimm-events? Should I need to turn off the event alarm after the notification logged? Thank you very much. QI _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
