Uli,
Seems I missed one thing about -D parameter for HPI clients.
When domain id is not specified there are two ways
- work with default domain
- work with default domain and all domains accessible from default domain.
Which way you bear in your mind?
Anton Pak
On Tue, 08 Jun 2010 16:12:28 +0400, Anton Pak <[email protected]>
wrote:
> 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
