Again inline.
Cheers,
Uli
> -----Original Message-----
> From: ext Anton Pak [mailto:[email protected]]
> Sent: Monday, October 18, 2010 5:15 PM
> To: [email protected]
> Subject: Re: [Openhpi-devel] Observation with missing domain 0
>
> My comments inline.
>
> Anton Pak
>
> On Mon, 18 Oct 2010 14:05:05 +0400, Kleber, Ulrich (NSN - DE/Munich)
> <[email protected]> wrote:
>
> > Hi Anton,
> > I think the domain x command in hpi_shell is fine that way and I
> > agree with most of your comments below.
> > A few questions remain open for me:
> >
> > - drt command:
> > Already today, the hpidomain client uses saHpiDrtEntryGet
> to display
> > the drt. May be we should extend hpi_shell to do the same.
>
> "domain" command without parameters also displays DRT for the
> current
> domain.
> So the DRT code is already present in hpi_shell.
Good.
>
> > We could introduce oHpiDomainList function or
> oHpiDomainGet or similar
> > function that walks the actual list of domains know by baselib.
> > That way there would be no compatibility issues.
>
> Yes, makes sense for me.
What about oHpiDomainGet with similar semantic as saHpiDrtEntryGet?
That is something like:
SaErrorT SAHPI_API oHpiDomainGet (
SAHPI_IN SaHpiDomainIdT DomainId,
SAHPI_OUT SaHpiDomainIdT *NextDomainId,
SAHPI_OUT SaHpiTextBufferT *host, // ip of the serving
daemon
SAHPI_OUT SaHpiUint16T port // port of the serving
daemon
);
When called with DomainId==SAHPI_UNSPECIFIED_DOMAIN_ID, the first valid
domain id and its host:port are output.
I would even voluteer to implement that ;-).
>
> > Would you prefer that instead of my original proposal to have
> > saHpiDrtEntryGet(OH_DEFAULT_DOMAIN_ID) display DRT of
> OpenHPI default
> > domain
> > and saHpiDrtEntryGet(SAHPI_UNSPECIFIED_DOMAIN_ID) display
> what baselib
> > knows?
> > Do you see other compatibility issues?
>
> I find it rather tricky.
> saHpiDrtEntryGet has no domain id parameter.
> So you would need to open session to OH_DEFAULT_DOMAIN_ID or
> SAHPI_UNSPECIFIED_DOMAIN_ID before.
OK.
>
> > Currently saHpiDrtEntryGet cannot find something in the
> drt's because
> > with
> > OpenHPI daemons they are always empty.
>
> True for now.
> I believe it will change sometimes.
Agree.
>
> >
> > - I agree that domains of the library are unrelated.
>
> Well, openhpiclient.conf may define a domain for OpenHPI
> daemon connected
> to
> Shelf Manager and may define a domain for OpenHPI deamon
> running on a
> Board Payload.
> Who would say the domains are unrelated if the Board is under
> the Shelf
> Manager control?
Agree that those are logically related. But HPI-Spec uses a term
"related" for domains linked together via the drt with or without
being peers (e.g. p.25ff).
>
> > - What is our expected behavior of the library if a session to the
> > default domain
> > cannot be opened? I think it still should be possible to
> retrieve the
> > domain
> > list somehow.
> > If we provide oHpiDomainList/oHpiDomainGet function, this would be
> > possible,
> > since it would work outside sessions.
>
> Cannot say now.
> May be it shall try to open session to any available domain
> defined in
> openhpiclient.conf.
Or added by something like oHpiDomainAdd or
oHpiDomainAddById(725472981).
And I'm not so happy locating openhpiclient.conf file by reading the
OPENHPICLIENT_CONF environment variable.
>
> >
> > - How may beers for the bargain? ;-)
>
> $1M in $100 bank notes packed in opaque case. :)
>
> >
> > Cheers,
> > Uli
> >
> >
> >> -----Original Message-----
> >> From: ext Anton Pak [mailto:[email protected]]
> >> Sent: Tuesday, October 05, 2010 1:18 PM
> >> To: [email protected]
> >> Subject: Re: [Openhpi-devel] Observation with missing domain 0
> >>
> >> Uli,
> >>
> >> I am thinking about removing domain listing option for
> >> "domain" command
> >> (when it is invoked without params).
> >> Now it just lists DRT for current domain.
> >>
> >> I feel it is better to introduce "drt" command and may be
> >> "list_all_domains_that_baselib_knows_about" command.
> >>
> >> See more comments inline.
> >>
> >> Anton Pak
> >>
> >> On Tue, 05 Oct 2010 13:14:47 +0400, Kleber, Ulrich (NSN -
> DE/Munich)
> >> <[email protected]> wrote:
> >>
> >> > Hi,
> >> > I am testing OpenHPI is multi domain environment.
> >> >
> >> > So I work with openhpiclient.conf defining some domains
> >> with id != 0,
> >> > that are served by daemons on other machines.
> >> > OpenHPI base library automatically creates a domain 0
> with daemon on
> >> > localhost:4743. But if that daemon is not running (or a
> >> defined domain 0
> >> > serving daemon is not running), we have the following behavior:
> >> > - Sessions can be opened to all domains where daemons are
> >> running (OK)
> >> > - Sessions to domain 0 cannot be opened (OK)
> >> > - Session to domain SAHPI_UNSPECIFIED_DOMAIN_ID cannot be
> >> opened (not
> >> > OK?)
> >> > P.28 in the spec, chapter 3.2.3, first paragraph somehow
> >> suggests that
> >> > the HPI implementation should select a domain id that
> can open a
> >> > session.
> >>
> >> Well.
> >>
> >> I think we fulfill the req:
> >>
> >> -----------------
> >> Which domain is accessed when SAHPI_UNSPECIFIED_DOMAIN_ID
> is used is
> >> implementation-specific, and may be different for
> different HPI Users.
> >> -----------------
> >>
> >> But there is definitely an issue with:
> >> -----------------
> >> 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.
> >> -----------------
> >>
> >> I like the idea of having artificial empty default domain
> >> with DRT only on
> >> library level.
> >> But there would be strong objections against due to
> >> compatibility with
> >> previous OpenHPI versions.
> >>
> >>
> >> > But it is hard to say which of the openhpiclient.conf
> >> entries should
> >> > be
> >> > selected.
> >> > - hpi clients without -D parameter return NO_RESPONSE (OK)
> >> > - hpi_shell returns NO_RESPONSE (not OK, since currently
> >> there is no way
> >> > to
> >> > start hpi_shell and then change domain, Anton is
> >> currently adding an
> >> > option for that)
> >>
> >> Yep.
> >>
> >> > - There is no API to determine which domains are defined,
> >> except reading
> >> > the
> >> > openhpiclient.conf file.
> >> > - Even if there would be DRT entries, there is no way to
> read them,
> >> > since no session to default domain can be opened.
> >>
> >> I am fine with it if the domains are considered as unrelated.
> >>
> >> > - After domains are created using oHpiDomainAdd (feature
> >> 3064532), those
> >> > domain ids cannot be retrieved by an API. Somehow we need
> >> to implement
> >> > feature 3025777.
> >>
> >> When we reach an agreement or make a bargain. :)
> >>
> >> >
> >> >
> >> > Comments?
> >> > Cheers,
> >> > Uli
> >> >
> >> >
> >> >
> >> >> -----Original Message-----
> >> >> From: ext Anton Pak [mailto:[email protected]]
> >> >> Sent: Monday, October 04, 2010 5:26 PM
> >> >> To: Kleber, Ulrich (NSN - DE/Munich)
> >> >> Subject: Re: support for oHpiDomainAdd and oHpiDomainAddById
> >> >> in hpi_shell
> >> >>
> >> >> Uli,
> >> >>
> >> >> Thanks!
> >> >> I get your point and start thinking about removing the
> >> second part of
> >> >> new domain functionality - switching to new domain.
> >> >> So the "newdomain" command shall be followed with "domain
> >> >> <id>" command
> >> >>
> >> >> As for domain 0, HPI implementation shall always provide it.
> >> >> May be your observations add some weight
> >> >> to Artificial Default Domain on Base Library Level idea.
> >> >>
> >> >> What say?
> >> >>
> >> >> My plan is to wait 3 days after final patch publication and
> >> >> then proceed
> >> >> with it.
> >> >> Bryan's Sutula Rule :)
> >> >>
> >> >> Anton Pak
> >> >>
> >> >> On Mon, 04 Oct 2010 19:18:41 +0400, Kleber, Ulrich (NSN -
> >> DE/Munich)
> >> >> <[email protected]> wrote:
> >> >>
> >> >> > Hi Anton,
> >> >> > works fine for me!
> >> >> > I also like the way, the syntax and the interactive
> >> paramter request
> >> >> > work.
> >> >> >
> >> >> > Two observations during my test:
> >> >> > - We (oHpiDomainAdd) allow only to add a domain that is
> >> >> already active.
> >> >> > That is: If there is no daemon running at the
> >> specified host:port,
> >> >> > the domain is rejected. This is different to
> >> openhpiclient.conf, I
> >> >> > think.
> >> >> > There the domains are defined and as long as nobody
> >> tries to open
> >> >> > a session, nobody notices.
> >> >> > - hpi_shell doesn't start if the domain 0 is not available.
> >> >> > I tried openhpiclient.conf with just one domain on a
> >> >> different host,
> >> >> > while
> >> >> > the daemon on localhost was not running. I get
> NO_RESPONSE from
> >> >> > session open.
> >> >> > So hpi_shell always tries to open domain 0 - even when no
> >> >> domain 0 is
> >> >> > defined
> >> >> > in openhpiclient.conf.
> >> >> >
> >> >> > Those observations don't affect your patch.
> >> >> >
> >> >> > When can we go forward committing more stuff?
> >> >> >
> >> >> > Cheers,
> >> >> > Uli
> >> >> >
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> From: ext Anton Pak [mailto:[email protected]]
> >> >> >> Sent: Monday, October 04, 2010 3:50 PM
> >> >> >> To: Kleber, Ulrich (NSN - DE/Munich)
> >> >> >> Subject: support for oHpiDomainAdd and oHpiDomainAddById
> >> >> in hpi_shell
> >> >> >>
> >> >> >> Hello!
> >> >> >>
> >> >> >> Just have uploaded a patch for this feature to SF tracker.
> >> >> >> Could you by any chance try it?
> >> >> >>
> >> >> >> Anton Pak
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> --------------------------------------------------------------
> >> ----------------
> >> > Beautiful is writing same markup. Internet Explorer 9 supports
> >> > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and
> DOM L2 & L3.
> >> > Spend less time writing and rewriting code and more time
> >> creating great
> >> > experiences on the web. Be a part of the beta today.
> >> > http://p.sf.net/sfu/beautyoftheweb
> >> > _______________________________________________
> >> > Openhpi-devel mailing list
> >> > [email protected]
> >> > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> >>
> >>
> >> --------------------------------------------------------------
> >> ----------------
> >> Beautiful is writing same markup. Internet Explorer 9 supports
> >> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> >> Spend less time writing and rewriting code and more time
> >> creating great
> >> experiences on the web. Be a part of the beta today.
> >> http://p.sf.net/sfu/beautyoftheweb
> >> _______________________________________________
> >> Openhpi-devel mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
> >>
> >
> >
> --------------------------------------------------------------
> ----------------
> > Download new Adobe(R) Flash(R) Builder(TM) 4
> > The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> > Flex(R) Builder(TM)) enable the development of rich
> applications that run
> > across multiple browsers and platforms. Download your free
> trials today!
> > http://p.sf.net/sfu/adobe-dev2dev
> > _______________________________________________
> > Openhpi-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>
>
> --------------------------------------------------------------
> ----------------
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich
> applications that run
> across multiple browsers and platforms. Download your free
> trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> Openhpi-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
