________________________________________
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Renier Morales [EMAIL
PROTECTED]
Sent: Monday, May 12, 2008 10:26 PM
To: [email protected]
Subject: Re: [Openhpi-devel] Regarding bug 1794430
[EMAIL PROTECTED] wrote on 05/09/2008 07:01:38 AM:
>>
>> The oh_add_alarm (openhpid/alarm.c +124) is causing the blank alarms
>> to be put into the file.
>> The oh_add_alarm is called by oh_detect_oem_event_alarm function
>> (openhpid/alarm.c +352) for creating (allocating memory) the alarm
>> structure and filling some of the fields.
>> The same logic is also present in oh_detect_resource_event_alarm,
>> oh_detect_sensor_event_alarm and oh_detect_resource_alarm functions.
>> These functions calls oh_add_alarm with 3rd parameter set to 0
>> (means save the alarm to file).
>>
>> Hence, whenever the oh_detect_oem_event_alarm (or
>> oh_detect_resource_event_alarm or oh_detect_sensor_event_alarm or
>> oh_detect_resource_alarm) gets executed, a blank alarm gets inserted
>> into DAT file.
>
>Not quite right on the source of blank alarms. oh_add_alarm creates alarms
>whenever an alarm condition is detected. All the functions you mentioned are
>the entry points for the detection of alarm >conditions.
>As far as I know, blank alarms get created when they are read from a
>previously persisted alarm. This is the area that needs focus. So alarms
>(non-blank) are being created fine, but if the daemon has been >configured to
>presist alarms to disk and the daemon is later restarted, the domain DAT will
>show some blank alarms.
>Jonathan, correct me if I'm wrong here as I'm speaking from memory.
[PGR] :
oh_add_alarm function creates the alarm structure if the second parameter is
NULL.
If the third parameter is 1, it means the alarm is read from DAT file.
Else if the third parameter is 0, it means that the alarm is needs to be put
into DAT file.
If the second parameter is NULL and third parameter is 0. Then, oh_add_alarm
creates an blank alarm structure and writes the same into the DAT file.
I will try to explain with an example:
The oh_detect_oem_event_alarm function calls the oh_add_alarm with second
parameter as NULL and third parameter as zero (src/alarm.c +352).
/* Severity is "alarming". Add/Create OEM alarm */
a = oh_add_alarm(d, NULL, 0);
if (!a) goto done;
oh_add_alarm allocates memory for new alarm structure and copies the passed
alarm structure, if it is not NULL (src/alarm.c +157.
In this scenario, since the second parameter is NULL, blank alarm is created.
a = g_new0(SaHpiAlarmT, 1);
if (alarm) { /* Copy contents of optional alarm reference */
memcpy(a, alarm, sizeof(SaHpiAlarmT));
}
oh_add_alarm fills up the generic fields of the alarm structure like timestamp
etc,.
If the third parameter is zero, then oh_add_alarm puts the newly created alarm
into DAT file (src/alarm.c +182).
if (!fromfile) {
__update_dat(d);
param.type = OPENHPI_DAT_SAVE;
oh_get_global_param(¶m);
if (param.u.dat_save) {
char dat_filepath[SAHPI_MAX_TEXT_BUFFER_LENGTH*2];
param.type = OPENHPI_VARPATH;
oh_get_global_param(¶m);
snprintf(dat_filepath, SAHPI_MAX_TEXT_BUFFER_LENGTH*2,
"%s/dat.%u", param.u.varpath, d->id);
oh_alarms_to_file(&d->dat, dat_filepath);
}
}
In this case, the blank alarm is written into DAT file.
The oh_detect_oem_event_alarm function fills the alarm structure fields after
the oh_add_alarm function returns successfully (src/alarm.c +).
a->Severity = event->Severity;
a->AlarmCond.Type = SAHPI_STATUS_COND_TYPE_OEM;
oh_entity_path_lookup(event->Source, &a->AlarmCond.Entity);
a->AlarmCond.ResourceId = event->Source;
a->AlarmCond.Mid = event->EventDataUnion.OemEvent.MId;
memcpy(&a->AlarmCond.Data,
&event->EventDataUnion.OemEvent.OemEventData,
sizeof(SaHpiTextBufferT));
The oh_add_alarm has written the blank alarm into DAT file before all the alarm
structure fields is populated.
When openhpi daemon is restarted, it reads the blank (written earlier) from the
DAT file and puts into DAT.
Regards,
Raghavendra PG
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
