Anton, Thanks so much for the replies. I have a couple of follow-up questions/comments below . . .
David c) On the DAT maintenance, you wrote: > > If sensor event contains current state in optional event data the DAT > will > be maintained according to that state. > See oh_detect_sensor_event_alarm() in openhpid/alarm.c > > However if you change deassertion mask for sensor that raised alarm, > the > alarm is to be removed from the DAT. > Function oh_detect_sensor_mask_alarm (openhpid/alarm.c) is called from > inside of saHpiSensorEventMasksSet(). > There is a comment: > > /* Find matching sensor alarms and compare alarm's state with > the deassert mask. If deassert for that state is being disabled > on the sensor, then remove the alarm. > */ > Unless I still don't understand something here, this would not seem to fix the issue raised in that bug. Say you have a sensor that has its event masks configured so that it sends events when an event state is asserted, but not when it is deasserted. This is the situation described in the bug report, and it says that as a result, an entry made in the DAT when the event state is asserted is never removed. Even if you pay attention to the sensor optional data field, there will still not be any events generated when the event state is deasserted, so the DAT entry would still stay, would it not? e) On DRT support > > Currently OpenHPI provides empty DRT. > We argued about the ways to design it but came to no conclusion. > OpenHPI has two parts: Base Library and Daemon. > Base Library talks to Daemon over network. > Base Library has openhpiclient.conf configuration file. > Daemon has openhpi.conf configuration file. > It is not clear which part shall maintain DAT. > Before 2.10 domains and DAT were on Daemon side. > Now we have domain configuration on Base Library side and One Daemon - > One > Domain rule. But, with this, it seems like the DAT, domain info, event queues, and DRT would still be in the daemon. Correct? > However Base Library can be used to connect to other HPI implementation > (not only to OpenHPI Daemon). > And the other HPI implementation may have its own way for domain/DRT > stuff. > And an OpenHPI daemon plug-in may have knowledge about other OpenHPI > daemon instances. > For example if there is HPI on the blade payload and the blade is just > come to ACTIVE state. > > Your thoughts look reasonable. Let's try to scratch architecture for > that. > My thoughts, so far, are simply that the DRT is nothing but a little table of domainIds, along with "isPeer" flags. There just needs to be a plug-in API to be able to insert or remove entries in the table. When an insertion or removal is made, generate a domain event. Then, add the messaging between library and daemon to handle the saHpiDrtEntryGet() function. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Openhpi-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openhpi-devel
