I have never seen voting in OpenHPI.
Anton Pak
On Tue, 08 Jun 2010 16:24:30 +0400, Kleber, Ulrich (NSN - DE/Munich)
<[email protected]> wrote:
> 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
------------------------------------------------------------------------------
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
