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
