On Fri, 2007-08-03 at 12:46 -0400, Renier Morales wrote:
> One thing is that the DATs between HPI instances will not necessarily
> be the same. It depends on whether both instances are receiving the
> same events that you will then see the same DATs. It is possible that
> while alarms 1-2 are detected on discovery of the resources, alarms
> 74/76 are not necessarily detected during resource discovery but
> during normal event polling. So if Blade 5 missed the events that
> would constitute alarms 74/75 because it was restarted, that would
> explain it.
>
I have restarted Blade 10 HPI daemon, now the 74/75 are gone, so Blade
10 missed to asserted false event? How did it miss it? That's not a
really reliable process?
> The HPI specification does not require the implementation to keep
> multiple instances in sync. It does require to keep multiple clients
> connecting to the same HPI instance in sync. Ids can definitely be
> different across instances and this is mentioned in the specification.
SAI-HPI-B.01.01 HPI Specification
3.6 Synchronization
...
There may be multiple HPI implementations present in a system, such as
those offered by different vendors. HPI Users should not assume any
synchronisation between different HPI implementations.
...
3.6.2 Multiple HPI implementations
...
Any software layer using concurrent access via multiple HPI
implementations should take appropriate care; for
example, by updating both RDR tables, reading most current sensor
values, etc., if it is possible that anything
may have had an effect on the other HPI implementation.
By "HPI implementation" the spec means instance of the daemon/library or
like in 3.6 different vendors?
Because from what I understand "different HPI implementations" means
e.g. one from OpenHPI and one from Motorola, I assume that both process
wont talk to each other to sync (even if most commercial HPI
implementation are based on OpenHPI :)). But two instances of OpenHPI
daemon for me share the same HPI implementation.
3.6.1 Synchronization Responsibilities
It is the responsibility of an HPI implementation to ensure that a
single, consistent view of the system and its
domains and resources is presented to all HPI Users. In the face of
multiple concurrent changes, the HPI
implementation should attempt to make updates visible system-wide in a
timely manner; however, no specific
timing is specified.
An HPI implementation shall guarantee that each HPI operation on any
resource is atomic; that is, if two writes
are attempted to a resource (e.g. from different sessions), one write
shall succeed entirely, and then the other
write shall succeed entirely. The order in which the writes occur may be
undefined, depending on timing and
the locations of the sources of the writes.
Any one HPI implementation is required to report all events for all
resources to all sessions which have
subscribed to receive events and which have visibility of those
resources.
Synchronization across sessions for me is just an example and one case
of where sync should occurs. But sessions from different daemon to the
same shmm should have a
consistent view of the system.
The spec is clear about that two vendors shouldn't sync, but it's not
very clear that it shouldn't across the same implementation. Any
Comments?
Regards,
/jonathan
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________ Openhpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
