[EMAIL PROTECTED] wrote on 09/12/2007 02:25:00
PM:
> I had seen the answer but maybe I am not sure to correctly
> understand the concept.
>
> Could you explain a little bit more the ?domain connection manager??
What we have now as standard is libopenhpi.so and openhpid. Running
openhpid creates a complete (monolithic?) HPI instace. All domains live
within that space. By linking to libopenhpi.so, you get access to that
instance over TCP.
The change that I was talking about is to, instead of having openhpid
house all of the domains, to have multiple openhpids, each representing
one domain. So we break the openhpid HPI instance into pieces at the
domain level.
Now we need to add logic to libopenhpi.so to know how to connect to
multiple daemons (which are now single domains). That involves making
libopenhpi.so map domain ids to ip/port numbers in order to communicate
with the domains (each now a daemon).
That logic is what I call the "domain connection manager", which would be
transparent to the API user, except for maybe a configuration file which
would have the domain id to ip/port map information, unless the mapping
can be done differently.
With that, I think that the domain relationships (e.g. peer) described in
the spec become more useful and meaningful.
>
> My understanding is that there will be 2 instance of OpenHPI running
> on 2 different blades. One of the instances will be connected to a
> domain and the second instance will have a peer connection to the
> same domain (same hardware). Right?
The idea is that the application linking to libopenhpi.so can be connected
to 2 domains (i.e. daemons) at the same time. Each one of these daemons
can be running anywhere on the network. Domains themselves can be peers of
one another. Peer domains give you access to the same set of hardware
resources. How these domains access hardware depends on the OpenHPI plugin
they use. Peer domains don't necessarily have to be using the same plugin
or same plugin configuration. One could be using a local-based plugin,
another a network-based plugin to get to the same hardware.
> Where will be the ?RAM? data
> storing all the information. II am not sure to fully understand
> how this will work but really interested in more discussions.
The domain instances (daemon processes) hold the domain data. Some of this
can be persisted to disk (e.g. domain alarm table, domain event log) in
order to survive a domain restart.
>
> We might be interested in contributing to OpenHPI to add this
> functionality. Is it something OpenHPI might be interested. Do you
> think that OpenHPI developers might help doing and supporting it.
Yes, we would be interested in a contribution like this. I'd be able to
provide help on this.
>
> By the way, do you have any other documentation than the HPI manual.
I'm afraid not. The HPI specification and OpenHPI manual is what we have
for now...
--Renier
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
