Uli,
See my comments inline.
> OK, I see now that the current behavior is also according to the
> comments in the openhpiclient.conf.example.
> So at least we warn the user about our behavior.
>
>
> So let me do a small experiment in my thoughts.
> Assume I create a plugin "default-domain-drt-provider".
> Then I configure a daemon with that plugin only and run it.
> For my openhpiclient.conf I configure 3 domains:
>
> domain default - daemon with default-domain-drt-provider-plugin,
> domain 1 - daemon for my real domain 1,
> domain 2 - daemon for my real domain 2.
>
> The task of the default-domain-drt-provider-plugin is now to
> process saHpiDomainInfoGet and saHpiDrtEntryGet with some info,
> it reads from the openhpiclient.conf. This domain would not
> provide any other resources.
>
> The above is only a thought-experiment. Probably we would need a
> complete daemon for the default-domain-drt-provider-plugin, since
> plugins normally shouldn't need to know about domains or do they?
> Also it is weird when that daemon reads the openhpiclien.conf.
>
> But perhaps the experiment helps to understand where we need to
> go.
>
Well, separate daemon for that task, it does not look fine.
However, Empty default domain with references in DRT only - sounds good.
But event HPI domain shall provide Event Log and Alarm Table along with DRT.
And there are HPI User functions to add an event log entry or alarm.
Looks rather clumsy and complicated.
Also administrator shall configure and run additional deamons.
> My tests so far worked fine when I provide the domain id 1 or 2.
> hpibrowser and hpi_shell support the domain ids.
>
> Btw. I find it ok, that the daemon always thinks it works on
> domain 0. Just assume that there are two clients with different
> openhpiclient.conf which use different domain ids to access the
> same daemon. As long as there are no peer domains there is no
> problem even with that. Of course better give the same domain id
> to a daemon.
Well, as I can remember from David's McKinley speech,
the HPI domain is just a collection of HPI resources.
The resources' grouping is done for administrative purpose.
It is not required for resources in one domain to be physically co-located.
A resource may be exposed via different domains.
For example:
Domain 1: res A, res B, res C
Domain 2: res A, res B
Domain 3: res A, res B
Domain 4: res A, res B, res D
Domain 2 and Domain 3 are peer domains.
> So maybe we define the domain id in the wrong place. A cleaner way
> would be to have the domain id defined for the daemon in openhpi.conf,
> and specify only the address for the daemon in openhpiclient.conf.
> This of course would be too big change and I didn't mean to propose it.
The idea of Registar service that holds domains' connectivity information
was discussed on HPI WG meetings.
openhpiclient.conf is very primitive realization of the Registrar concept.
There are also discussion about DRT implementation on base library level.
Current openhpiclient.conf is:
-----------------
domain 1 { host=h1; port = p1; }
domain 2 { host=h2; port = p2; }
default { host=h3; port = p3; }
We argued around the following schema for openhpiclient.conf:
----------------------------
domain 1 { host=h1; port=p1; translateto=d1; references="2,3" };
domain 2 { host=h2; port=p2; translateto=d2; references="1"; }
domain 3 { host=h3; port=p3; translateto=d3; references="1"; }
default = 1;
TranslateTo parameter shows domain_id on the daemon side.
A daemon (may be not OpenHPI daemon) may expose several domains.
The schema will allow to have several domains with the same host:port.
>
> Sorry, that email got too long.
Me too! :)
>
> Cheers,
> Uli
>
>
>
>
>
>> -----Original Message-----
>> From: ext Anton Pak [mailto:[email protected]]
>> Sent: Friday, June 04, 2010 3:17 PM
>> To: [email protected]
>> Subject: Re: [Openhpi-devel] Domain Support for Clients
>>
>> 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
>>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
