Will do. I need to do some internal process clarification however, before I can send the full set of patches.
Cheers, Uli > -----Original Message----- > From: ext SourceForge.net [mailto:[email protected]] > Sent: Monday, June 07, 2010 3:04 PM > To: [email protected] > Subject: [ openhpi-Bugs-3011456 ] Domain Support for Clients > > Bugs item #3011456, was opened at 2010-06-04 13:02 > Message generated for change (Comment added) made by avpak > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=532251&aid=3 011456&group_id=71730 > > Please note that this message will contain a full copy of the > comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: HPI Clients > Group: None > Status: Open > Resolution: None > Priority: 5 > Private: No > Submitted By: Ulich Kleber (ulikleber) > Assigned to: Anton Pak (avpak) > Summary: Domain Support for Clients > > Initial Comment: > The OpenHPI clients always work with the default domain, even > if the openhpiclient.conf file specifies domains. > There is no possibility to use them on other domains or in a > multi domain configuration. > > All clients should read the openhpiclient.conf file (as > hpishell does) and provide options to target a specific domain. > > If the openhpiclient.conf defines no domain, the default > domain should be used. > > If the openhpiclient.conf defines one domain, the clients > should use the specified domain if no other option is given. > > If the option specifies a domain, that is not defined in > openhpiclient.conf, the clients should exit with an error. > > If the openhpiclient.conf defines multiple domains, and the > client is invoked with no domain option, in many cases the > clients should work on all domains. > For instance hpitop, hpitree and hpiinv should display all domains. > In some cases, for instance hpipower, the domain may be > mandatory to perform the action. > > > ---------------------------------------------------------------------- > > >Comment By: Anton Pak (avpak) > Date: 2010-06-07 17:03 > > Message: > Looks fine for me. > My only proposal is to move -D in the head of the options > list since it is > most important parameter. > > > ---------------------------------------------------------------------- > > Comment By: Ulich Kleber (ulikleber) > Date: 2010-06-07 16:58 > > Message: > The attached patch provides an additional option to hpitop > (as an example), > that allows hpitop to be executed on a selected domain. > Example: hpitop -D 2 will execute the client program on the > domain 2 if > there is such a domain defined in the openhpiclient.conf. > I also fixed a few other problems within the scanning of options. > > If this is a step 1 for the multi domain issues, I would > provide similar > patch for all clients. > > ---------------------------------------------------------------------- > > Comment By: Anton Pak (avpak) > Date: 2010-06-04 14:35 > > Message: > I like the idea about DRT. > However peer domain is not what we want. > Base HPI spec says (Section 3.2.2): > ------------------------------------------------------ > Two domains, domain-A and domain-B, are "peers" if they are intended > to provide an HPI User with access to the same set of resources. > ------------------------------------------------------ > > Also the special handling of DRT in baselib may interfere with DRT > implementation in daemon. > However I don't think that anybody currently uses DRT on daemon level. > But the code still exists. > Also OpenHPI baselib may be used to connect to another HPI > implementation > with its own multi-domain concept. > > I guess we need to develop new whole multi-domain architecture before > starting to write code. > May be on daemon level. May be on baselib level. > What say? > > ---------------------------------------------------------------------- > > Comment By: Ulich Kleber (ulikleber) > Date: 2010-06-04 14:22 > > Message: > I think "all defined domains" means the content of openhpiclient.conf. > Different clients today can use different openhpiclient.conf > files at the > same time and thus access different sets of domains. There is > no way to get > a global view over many openhpiclient.conf files. But a > client always has a > openhpiclient.conf used by the library, which defines the > domains visible > for that client. > > I think we should see all domains visible for a client (as > defined in the > openhpiclient.conf) as peer domains for the default domain. > That is, even when OpenHPI doesn't (yet?) implement the DRT fully, we > could provide SaHpiDrtEntryGet() for the default domain to > provide such > functionality. > > So what we need to do is: > - implement SaHpiDrtEntryGet in baselib > - clients should call SaHpiDrtEntryGet instead of reading > openhpiclient.conf as I said above (sorry.) > - create an additional client hpidomains that provides a list > of domains > (or in future some domaininfo) > > (I volunteer to contribute to that work) > > ---------------------------------------------------------------------- > > Comment By: Anton Pak (avpak) > Date: 2010-06-04 13:34 > > Message: > Agreed. > Could you propose generic HPI way to get domain id for all defined > domains? > > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=532251&aid=3 011456&group_id=71730 > ------------------------------------------------------------------------------ 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
