As I can see from baselib/oh_client_session.cpp, function oh_client_init
algorithm is (in pseudo-code):
-----------------
oh_load_client_config( $OPENHPICLIENT_CONF or OH_CLIENT_DEFAULT_CONF );
if ( there was default domain desciption in client config ) {
// Life is good
} else {
host = $OPENHPI_DAEMON_HOST or localhost
port = $OPENHPI_DAEMON_PORT or 4743;
create default domain description with host:port;
}
-----------------
There is also a comment (which I believe Renier made) about
$OPENHPI_DAEMON_HOST and $OPENHPI_DAEMON_PORT
/* TODO: change these envs to have DEFAULT in the name*/
I like this idea.
Also there is some trick with domain_id mapping.
The openhpid is currently support only one domain with id = 0;
And the domain id assignment is performed on client level according with
openhpiclient.conf information.
The code also maps domain_id parameter in SaHpiXXX data structures:
- SaHpiDomainEventT
- SaHpiConditionT
- SaHpiDomainInfoT
Not sure about SaHpiDrtEntryT.
You see domain stuff is currently quite a mess :)
Anton Pak
On Fri, 04 Jun 2010 16:44:38 +0400, Kleber, Ulrich (NSN - DE/Munich)
<[email protected]> wrote:
> Hi,
> let's move the architeture discussion from the tracker to the
> development list
>
> I agree, real peer domains are somewhat different to the case
> when a default domain shall be found via the default domain.
>
> I didn't look into the existing DRT implementation yet. Maybe
> we need to understand what doees the existing stuff do. I agree
> that we need to analyze thoroughly before changing things there.
>
> I don't think the default domain should provide a full DRT. But
> in a case when the library is configured to work with domains
> 1 and 2, we can easily make the call
> saHpiDomainInfoGet(SAHPI_UNSPECIFIED_DOMAIN_ID,.. and
> saHpiDrtEntryGet(SAHPI_UNSPECIFIED_DOMAIN_ID,..
> provide some useful information.
>
> What is the baselib expected to do when domain
> "SAHPI_UNSPECIFIED_DOMAIN_ID" is opened, but only two other domains
> are defined? At least, opening a session shouldn't just call
> the local openhpid on the default port - but that's what I
> observe. My openhpiclient.conf defines domain 1 and 2, but still
> domain 0 contains all hardware, which the local daemon can access.
>
>
> What we could start to do in the meantime, would be that the clients
> can access single domains by their id.
> Should I start on that?
>
> Cheers,
> Uli
>
>
>
>
>
>> -----Original Message-----
>> From: ext SourceForge.net [mailto:[email protected]]
>> Sent: Friday, June 04, 2010 12:35 PM
>> To: [email protected]
>> Subject: [ openhpi-Bugs-3011456 ] Domain Support for Clients
>>
>> Bugs item #3011456, was opened at 2010-06-04 13:02
>> Message generated for change (Comment added) made by avpak
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=532251&aid=3
> 011456&group_id=71730
>>
>> Please note that this message will contain a full copy of the
>> comment thread,
>> including the initial issue submission, for this request,
>> not just the latest update.
>> Category: HPI Clients
>> Group: None
>> Status: Open
>> Resolution: None
>> Priority: 5
>> Private: No
>> Submitted By: Ulich Kleber (ulikleber)
>> Assigned to: Anton Pak (avpak)
>> Summary: Domain Support for Clients
>>
>> Initial Comment:
>> The OpenHPI clients always work with the default domain, even
>> if the openhpiclient.conf file specifies domains.
>> There is no possibility to use them on other domains or in a
>> multi domain configuration.
>>
>> All clients should read the openhpiclient.conf file (as
>> hpishell does) and provide options to target a specific domain.
>>
>> If the openhpiclient.conf defines no domain, the default
>> domain should be used.
>>
>> If the openhpiclient.conf defines one domain, the clients
>> should use the specified domain if no other option is given.
>>
>> If the option specifies a domain, that is not defined in
>> openhpiclient.conf, the clients should exit with an error.
>>
>> If the openhpiclient.conf defines multiple domains, and the
>> client is invoked with no domain option, in many cases the
>> clients should work on all domains.
>> For instance hpitop, hpitree and hpiinv should display all domains.
>> In some cases, for instance hpipower, the domain may be
>> mandatory to perform the action.
>>
>>
>> ----------------------------------------------------------------------
>>
>> >Comment By: Anton Pak (avpak)
>> Date: 2010-06-04 14:35
>>
>> Message:
>> I like the idea about DRT.
>> However peer domain is not what we want.
>> Base HPI spec says (Section 3.2.2):
>> ------------------------------------------------------
>> Two domains, domain-A and domain-B, are "peers" if they are intended
>> to provide an HPI User with access to the same set of resources.
>> ------------------------------------------------------
>>
>> Also the special handling of DRT in baselib may interfere with DRT
>> implementation in daemon.
>> However I don't think that anybody currently uses DRT on daemon level.
>> But the code still exists.
>> Also OpenHPI baselib may be used to connect to another HPI
>> implementation
>> with its own multi-domain concept.
>>
>> I guess we need to develop new whole multi-domain architecture before
>> starting to write code.
>> May be on daemon level. May be on baselib level.
>> What say?
>>
>> ----------------------------------------------------------------------
>>
>> Comment By: Ulich Kleber (ulikleber)
>> Date: 2010-06-04 14:22
>>
>> Message:
>> I think "all defined domains" means the content of openhpiclient.conf.
>> Different clients today can use different openhpiclient.conf
>> files at the
>> same time and thus access different sets of domains. There is
>> no way to get
>> a global view over many openhpiclient.conf files. But a
>> client always has a
>> openhpiclient.conf used by the library, which defines the
>> domains visible
>> for that client.
>>
>> I think we should see all domains visible for a client (as
>> defined in the
>> openhpiclient.conf) as peer domains for the default domain.
>> That is, even when OpenHPI doesn't (yet?) implement the DRT fully, we
>> could provide SaHpiDrtEntryGet() for the default domain to
>> provide such
>> functionality.
>>
>> So what we need to do is:
>> - implement SaHpiDrtEntryGet in baselib
>> - clients should call SaHpiDrtEntryGet instead of reading
>> openhpiclient.conf as I said above (sorry.)
>> - create an additional client hpidomains that provides a list
>> of domains
>> (or in future some domaininfo)
>>
>> (I volunteer to contribute to that work)
>>
>> ----------------------------------------------------------------------
>>
>> Comment By: Anton Pak (avpak)
>> Date: 2010-06-04 13:34
>>
>> Message:
>> Agreed.
>> Could you propose generic HPI way to get domain id for all defined
>> domains?
>>
>>
>> ----------------------------------------------------------------------
>>
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=532251&aid=3
> 011456&group_id=71730
>>
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
