#596 Support for domain discovery

2.15.1
closed-fixed
Ulich Kleber
5
2010-11-29
2010-07-06
Ulich Kleber
No

OpenHPI currently supports multiple domains in the following way:

- Openhpiclient.conf defines domains and associates daemons (IP-address:port)
with the domains
- A domain with id "0" is implicitely defined and associated with a daemon
on localhost 4743.
- Openhpiclient.conf can define a different domain 0 (default).
- HPI B.03 defines a value SAHPI_UNSPECIFIED_DOMAIN_ID=0xFFFFFFFF for a
specific behavior allowing clients to locate domains via the DRT.
- When I use OpenHPI to open a session to SAHPI_UNSPECIFIED_DOMAIN_ID,
OpenHPI opens a session to domain 0, which is correct to the spec.
- OpenHPI always provides an empty DRT, even when multiple domains are
defined in openhpiclient.conf.
- If a user knows which domains are defined in the openhpiclient.conf,
he can open sessions to these domains.

HPI B.03.2 says in section 3.2.3, second paragraph:
To support the general discovery process described in Section 3.5,
HPI implementations should ensure that all the domains that a user
needs to access are related and are discoverable from the default
domain returned when the user opens a session specifying
SAHPI_UNSPECIFIED_DOMAIN_ID.

That would mean, when specifying SAHPI_UNSPECIFIED_DOMAIN_ID, a user
can walk the DRT and discover valid domain ids.
Considering the way, domains are defined in OpenHPI, that would mean,
he can find all domains specified in "his" openhpiclient.conf file
that way.

So OpenHPI library should provide a user with access to a DRT with
those domain ids when he opens a session with SAHPI_UNSPECIFIED_DOMAIN_ID.

Discussion

  • Anton Pak
    Anton Pak
    2010-07-06

    My proposal was to introduce empty default domain with DRT only.
    DRT content would be defined in openhpiclient.conf.
    For openhpiclient.conf it would be useful do define several Domain Ids for the same pair of host:port.
    Also there was a proposal to introduce domain id mapping schema. The local domain id and hot it was mapped to remote (openhpid side) domain id. See the discussion in mailing list previous month.

     
  • Ulich Kleber
    Ulich Kleber
    2010-11-24

    • milestone: --> 898633
     
  • Ulich Kleber
    Ulich Kleber
    2010-11-24

    After some discussion the following solution is implemented. It is base on an OpenHPI specific new function that helps discover the domains known to the library:
    SaErrorT SAHPI_API oHpiDomainEntryGet (
    SAHPI_IN SaHpiEntryIdT Entry,
    SAHPI_OUT SaHpiEntryIdT *NextEntry,
    SAHPI_OUT oHpiDomainInfoT *DomainInfo
    );
    with
    typedef struct {
    SaHpiDomainIdT id,
    SaHpiTextBufferT daemonhost,
    SaHpiUint16T port
    } oHpiDomainInfoT;

    Like in saHpiDrtEntryGet, the user would walk the list of domains, starting with SAHPI_FIRST_ENTRY, and read all defined domain ids until NextEntry==SAHPI_LAST_ENTRY is returned.

    There will also be a client program to help the user on the command line interface.

    The attachments contain an implementation.

     
  • Ulich Kleber
    Ulich Kleber
    2010-11-24

    Patch implementing oHpiDomainEntryGet

     
  • Ulich Kleber
    Ulich Kleber
    2010-11-24

    New client program ohdomainlist

     
    Attachments
  • Ulich Kleber
    Ulich Kleber
    2010-11-24

    man entry for ohdomainlist

     
    Attachments
  • Ulich Kleber
    Ulich Kleber
    2010-11-24

    Patch to activate the new client ohdomainlist

     
  • Ulich Kleber
    Ulich Kleber
    2010-11-24

    The 4 attached files are now present. They were tested based on revision 7166.

     
  • Ulich Kleber
    Ulich Kleber
    2010-11-24

    • assigned_to: avpak --> ulikleber
     
  • Ulich Kleber
    Ulich Kleber
    2010-11-25

    Fixed in Revision 7166

     
  • Ulich Kleber
    Ulich Kleber
    2010-11-25

    • status: open --> closed-fixed
     
  • Anton Pak
    Anton Pak
    2010-11-29

    • milestone: 898633 --> 2.15.1