RE: [Openhpi-devel] Some confusion about API and structure (LogEn tryAdd)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Andy,

You can see the API description about add event log entry.

SaErrorT SAHPI_API saHpiEventLogEntryAdd (
	SAHPI_IN SaHpiSessionIdT	SessionId,
	SAHPI_IN SaHpiReosurceIdT	ResourceId,
	SAHPI_IN SaHpiSelEntryT	*EvtEntry
);

SAHPI_IN means the parameters in input to the function, and will not
returns to the user. If the parameter will be filled/changed, it will be =

SAHPI_OUT. In your opnion1, if API will return us the EntryId, and other
part of it will be filled with us. The type of EvtEntry should be =
SAHPI_INOUT.
For instance:=20

SaErrorT SAHPI_API saHpiEventLogEntryGet(
	...
	SAHPI_INOUT SaHpiRdrT	*Rdr...
);
So though the first idea sounds good and reasonable, but it conflict =
with the
spec. Our implementation and plan must be conform the API is the base =
line
for us.=20

You nean user cannot change the eventlog information, just because the =
customer
use these information to track the problem. However you see, it protects =
delete
eventlog entry, even though delete all event log entry. So if I delete =
the newest=20
entry and add a new entry, after a while it is the same as I update a =
old entry.
So I think this function is the flexibility to user, otherwise if the =
resource support
the delete function, customer still can change old log info.=20

Thanks=20

-Kevin

-----Original Message-----
From: Cress, Andrew R=20
Sent: 2003?5?29? 21:53
To: ope...@li...
Cc: Todd, Charlene J
Subject: RE: [Openhpi-devel] Some confusion about API and structure =
(LogEn tryAdd)

Kevin,

Well, I can, from a customer perspective, know for certain that allowing
someone to write (spoof) an Event record to the firmware log with an
out-of-sequence Event ID, or especially an old date, will cause major
customer problems.  From many years of experience, I know that =
customers,
and customer support personnel, rely on the order of events and the
date/time stamps to determine what problems occurred in what order on a
given system.  If the HPI spec allows this, the spec needs to be =
corrected
or explained better.=20

We know that EventID must be the key for parsing these entries, so it is =
all
the more important to make sure that it is (1) unique, and (2) ordered, =
so
that events logged at a later time have higher EventIDs.  Allowing this =
to
be passed in from outside without validating it (or generating it) is =
asking
for trouble. =20
There are two possible solutions, as I see it:
1) The HPI library generates a valid EventID and current Date/Time stamp
when LogEntryAdd is called and the EventID is returned to the caller.
and/or
2) The HPI library validates that the EventID passed is greater than the
latest existing entry, and that the date is correct (current).  An error =
is
returned otherwise.
Since the code will have to get all the information in the HPI library
anyway, option (1) seems better to me.

Charlene,=20
Can you please log this as an errata on the HPI 1.0 spec?  I know that =
there
are more changes for LogEntryAdd in HPI 1.1 anyway, so this issue could =
be
addressed as well.

Andy

-----Original Message-----
From: Gao, Kevin [mailto:kev...@in...]=20
Sent: Wednesday, May 28, 2003 8:59 PM
To: ope...@li...
Subject: RE: [Openhpi-devel] Some confusion about API and structure.

Hi Andy,

	In spec, you can see the description of parameter EvtEntry, it says
that,
EvtEntry-[in] Pointer do event log entry data to write to the system =
event
log.

	So it does not note that the "EntryId" of EvtEntry is invalid, so we
could not
make the conclusion self-assertively. And when user add the entry, the =
Entry
ID
I think is most important thing to user to process the entry they add. =
If
the entry
id is generated by system. User find and process the entry will have =
much
more
difficuilt, and this choise does not merge the spec else.

-Thanks
-Kevin

-----Original Message-----
From: Cress, Andrew R=20
Sent: 2003?5?27? 21:58
To: ope...@li...
Subject: RE: [Openhpi-devel] Some confusion about API and structure.

I'd propose=20
Choice 4:
For Delete, the EntryID must be an existing entry, and the entire entry =
is
deleted, including ID.
For Add, the EntryID is not relevant as input and the new entry goes =
into
the newest unused ID (and current date/time), so that the real ordering =
of
entries is preserved. =20

I believe that doing an Add where it is possible to add an entry out of
order would be unreasonable (broken). =20

Andy

-----Original Message-----
From: Gao, Kevin [mailto:kev...@in...]=20
Sent: Monday, May 26, 2003 5:38 AM
To: OpenHPI Mailing List
Subject: [Openhpi-devel] Some confusion about API and structure.

When I read the OpenHPI specification, I found 2 issue=20
still could not resolve.

1. Function saHpiEventLogEntryAdd/EventLogEntryDelete

I don't know when invoke the function saHpiEventLogEntryAdd=20
with specified parameter EvtEntry. The EvtEntry contained=20
attribute EntryId, I want to know how does the function work?

Choise 1:
    All the entry id of the whole entry is static, Delete entry
only will not remove entry ID, entry is still alive, and can be
get by function saHpiEventLogEntryGet, but the other field of the
data is cleared. And Invoke saHpiEventLogEntryAdd, API should=20
check parameter "EvtEntry.EntryId" and set the data of the=20
target entry. The old data in the specified position should be
replaced. If there is no entry id is equal to echEvtEntry.EntryId,
we cannot add the EvtEntry, and error code will be returned.

Choise 2:
    The API does not care the EvtEntry.EntryId, it only append=20
the data we add to the NEWEST_POSTION of the event log entry.
There is no limited about entry_id, or number. But when we want
to delete the entry with the specified id, we cannot do it=20
properly, just because the same entry id when we add is valid.
So, I think this idea must unreasonable.

Choise 3:
    When invoke the function saHpiEventLogEntryAdd, The API=20
should track the whole banch of the event log entry, if there
is the same entry id as the parameter EvtEntry.EntryId, then
API could throw an error code, or replace it. otherwise, the
API will append the error code, (for optimization, we can=20
sort the event log entry).=20

I think Choise 1 is reasonable, but it lose some availability,
When user want to add one entry, user should always invoke the=20
function saHpiEventLogEntryGet.
Choise 2 is unreasonable.
Choise 3 maybe something reasonable,but the efficiency of it=20
is still very bad among get, add delete the entry.=20

2. The struct of the SaHpiSensorThdDefnT

It's defination is as follow:
typedef struct {
		.
		.
		.
	SaHpiSensorThdMaskT	ReadThold;	/* Readable thresholds */
	SaHpiSensorThdMaskT	WriteThold; /* Writable thresholds */
	SaHpiSensorThdMaskT	FixedThold; /* Fixed thresholds */=09
};

The meaning of the sub variable ReadThold, and WriteThold is cleared.
But What does fixed thresholds mean?=20

The description of these issues in spec is uncleared, so could
you give me some idea or support.
   =20

Thank
-Kevin

-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Openhpi-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openhpi-devel

-------------------------------------------------------
This SF.net email is sponsored by: ObjectStore.
If flattening out C++ or Java code to make your application fit in a
relational database is painful, don't do it! Check out ObjectStore.
Now part of Progress Software. http://www.objectstore.net/sourceforge
_______________________________________________
Openhpi-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openhpi-devel

-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Openhpi-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openhpi-devel

-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Openhpi-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openhpi-devel

-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Openhpi-devel mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openhpi-devel