David,
See my comments below.
Anton Pak
On Tue, 20 Sep 2011 07:25:46 +0400, David McKinley <[email protected]>
wrote:
> 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?
>
I didn't say it was fixed. :)
And in IPMI when you clear some sensor event mask, you will see no event
from the sensor.
Sensor event generation may be disabled in hardware.
How can plug-in (potentially remote one) determine that event state become
deasserted without event?
I see 2 ways:
o) For many sensors state deassertion leads to assertion of another state.
So we can get
assertion event and then fill HPI event optional data with current state.
o) Periodic sensor state polling.
>
>
> 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?
Yes, they are still in the daemon. Until we come with better design.
Some information is translated in Base Library.
For example daemon always thinks that its domain id is zero.
Base Library makes domain id translation according to domain id defined in
openhpiclient.conf or oHpiDomain*() API. This translation alters
DomainInfo,
DrtEntry, DomainEvent, Alarm.
Base Library is also able to extend all entity paths coming from the
daemon by adding specified prefix.
>
>
>> 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.
Also plug-in may not be aware of domains configured by other plug-ins and
in openhpiclient.conf.
The library can be used to talk to many daemons.
There shall be no conflicts in Domain Ids.
So we need some translation layer.
It is not clear what is relationship between domains defined in
openhpiclient.conf.
Shall they be a part of DRT for event known domain?
------------------------------------------------------------------------------
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
