Uli, Your cases 1,2,3 looks good.
The alternative way is to provide default domain in any case. Just empty domain and DRT referring to domains from openhpiclient.conf. It will be simplier to implement and architecture will be more clear. However, I have no strong preference to any of these two ways. May be we shall use well-known (non zero) DomainId for the User Library Default Domain. Say 42 for example? :) For the domain we may have: - SaHpiDomainInfo.DatUserAlarmLimit = 0; (Argh! 0 means no limit according to Sahpi.h) - SaHpiEventLogInfoT.Size = 0 - Empty SaHpiEventLogCapabilitiesT - some tricks with saHpiEventGet/saHpiEventAdd, added event shall appear at any session event queue. > Then why is it defined in the openhpiclient.conf? Shouldn't all > infos that the daemon needs be to know be defined in openhpi.conf? I think only the Daemon Domain Id is ok for openhpi.conf. Currently any daemon just provides domain 0. > Why would we need to have multiple domains with the same host:port? > I think OpenHPI's idea to have a daemon implementing exactly one domain > is a nice principle. Well, 2.8 and 2.10 had multiple domain support on daemon level. openhpiclient.conf is 2.12 innovation. I know two more HPI implementation that may be used with OpenHPI client library. PPS has one of them. The domain architecture for another HPI implementation may be different. I don't think we shall shut the door for other HPI implementations. Such scalability is one of OpenHPI strenghtes. Anton Pak > Hi Anton, > > see some comments inline. > Sorry for the confusion with the thought experiment. > > I read again what the spec says about the default domain and I also > remember a speech by DavidM, that the default domain is not a real > domain. > The default domain is accessed via SAHPI_UNSPECIFIED_DOMAIN_ID, > which is 0xFFFFFFFF. > > The spec says on p.28: > 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. > When a domain is accessed with SAHPI_UNSPECIFIED_DOMAIN_ID, the > actual domain identifier associated with the domain may be obtained > from the DomainInfo structure returned by the saHpiDomainInfoGet() > function. > > So I think that's what we should provide: > > Case 1, when openhpiclient.conf defines no domain: > > - When the user opens a session with > domain-id=SAHPI_UNSPECIFIED_DOMAIN_ID, > we open the session with the default daemon (localhost:4743). > - When the user calls saHpiDomainInfoGet() we provide domain-id 0. > - When the user opens a session with domain-id=0, the same happens. > - When the user tries to access another domain, we return > SA_ERR_HPI_INVALID_DOMAIN > > > Case 2, when openhpiclient.conf defines one single domain (let's use > id=1): > > - When the user opens a session with > domain-id=SAHPI_UNSPECIFIED_DOMAIN_ID, > we call the daemon as defined for domain-id 1 > - When the user calls saHpiDomainInfoGet() we provide domain-id 1. > - When the user opens a session with domain-id=1, the same happens. > - When the user tries to access another domain, we return > SA_ERR_HPI_INVALID_DOMAIN > > > Case 3, when openhpiclient.conf defines multiplee domains (for the > example > let's use two domains id 1 and 2) > > - When the user opens a session with > domain-id=SAHPI_UNSPECIFIED_DOMAIN_ID, > we don't call a daemon. > - When the user calls saHpiDomainInfoGet() we provide domain-id 0. > But there are no resources. Maybe even events are not needed (there > could be > events with type domain. But we don't change the set of domains that > are > defined - that is are on DRT of default domain, so we will never issue > such > event) > - The user should call saHpiDrtEntryGet() in this session to read which > domains > are defined. > We don't implement peer domains, so all domains are "related non-peer > domains" > as described on p.26. > - The user then should open sessions with domains 1 and 2. And work with > them. > - I think the DRT of domain 1 and 2 can still be empty. > > Currently we have defined domain 0 in all cases, always fixed to the > daemon > localhost:4743. This behavior is ok for all cases. If somebody doesn't > like > that domain, he can avoid starting that daemon and use a different port. > > > Is this the behavior we need in a first step? > When we agree on that we can start to discuss how we implement it in our > > architecture. > In later steps, real domains could have related non-peer domains, and in > later > future we could go to peer domains. > > > Btw. Do you think we could - independent of this discussion, add an > option to the > clients so they can work with a given domain? E.g. hpitop -did 3 would > just work > with domain 3? > > > Cheers, > Uli > >> -----Original Message----- >> From: ext [email protected] >> [mailto:[email protected]] >> Sent: Friday, June 04, 2010 7:53 PM >> To: [email protected] >> Cc: [email protected] >> Subject: Re: [Openhpi-devel] Domain Support for Clients >> >> 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. > > It was just for my experiment, not for implementation. So drop it. > > >> 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. > > Maybe we don't need the events (see above), so is it still clumsy? > >> Also administrator shall configure and run additional deamons. > > I don't know what you mean with that. Other OpenHPI-like daemons, that > would be additional domains, which can be found only via the > openhpiclient.conf ? Those would be no problem, as long as we stick > with the principle 1 daemon = 1 domain. > > >> >> >> > 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. > > I fully agree. > >> 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. > > Then why is it defined in the openhpiclient.conf? Shouldn't all > infos that the daemon needs be to know be defined in openhpi.conf? > > >> A daemon (may be not OpenHPI daemon) may expose several domains. >> The schema will allow to have several domains with the same host:port. >> > > Why would we need to have multiple domains with the same host:port? > I think OpenHPI's idea to have a daemon implementing exactly one domain > is a nice principle. > > > >> >> > >> > 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 >> > > ------------------------------------------------------------------------------ > 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
