Hi Anton, we at NSN don't need peer domains at this point. We also don't need another default domain id. What we would like to use is the usage of SAHPI_UNSPECIFIED_DOMAIN_ID to discover domains. So I am fine with both ways.
How does voting in OpenHPI work? Cheers, Uli > -----Original Message----- > From: ext Anton Pak [mailto:[email protected]] > Sent: Tuesday, June 08, 2010 2:12 PM > To: [email protected] > Subject: Re: [Openhpi-devel] Domain Support for Clients > > Uli, > > Well, not sure we can break it. > However it is pretty looking architecture solution. > Let's make a voting! :) > > As for default domain id, I suggest to make a number that > helps to avoid > collision. > I hope implementors using reasonable numbers in their HPI > implementation. > > As for peer domains, not sure there are men liking to have it > implemented. > What is the NSN position for peer domains? > > > Anton Pak > > On Tue, 08 Jun 2010 15:04:39 +0400, Kleber, Ulrich (NSN - DE/Munich) > <[email protected]> wrote: > > > Hi Anton, > > see answers inline. > > > > Cheers, > > Uli > > > > > >> -----Original Message----- > >> From: ext [email protected] > >> [mailto:[email protected]] > >> Sent: Tuesday, June 08, 2010 11:56 AM > >> To: [email protected] > >> Subject: Re: [Openhpi-devel] Domain Support for Clients > >> > >> 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. > > > > So you mean the openSession(SAHPI_UNSPECIFIED_DOMAIN_ID) in > all cases > > has no resources, but only DRT. > > I agree, and even would prefer it. > > But I expect the typical user today when having only 1 domain with > > empty openhpiclient.conf (so daemon on localhost:4743), > will use that > > coding. So my proposal was already a compromise for client > > compatibility. > > If you think we can break that, I would prefer your alternative. > > > >> > >> 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. > >> > > > > I think the zero DomainId is fine for that - even if we created some > > default characteristics that are not optimal. > > But if we create another value, I don't think it should be > the answer > > on all of our questions :), may be 0x80000000? > > But do we really need that? > > > > > >> > 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. > > > > Right. Today the daemon doesn't need to know. > > But if we introduce peer domains in OpenHPI 2.42, it might > need to know. > > I am fine with not changing that for now. > > > > > >> > >> > 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. > > > > OK. > > I don't know about history. > > > >> > >> 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. > > > > I fully agree. > > > > Cheers, > > Uli > > > >> > >> 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. > >> > > >> > > > > > ... snip > > deleted old stuff. > > > > > > > > > -------------------------------------------------------------- > ---------------- > > 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
