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
