On Tue, 20 Sep 2011 18:58:30 +0400, David McKinley <[email protected]> wrote:
> Hi Anton, > > On the DAT bug issue, you wrote: > >> >> I didn't say it was fixed. :) >> > > Hmm. I guess I was misled by the Tracker report saying "Closed/Fixed" > with the comment, "fixed in trunk". :-) > Well, possibly it wasn't fixed enough. > On the other hand, good point about: > >> o) For many sensors state deassertion leads to assertion of another >> state. >> So we can get >> assertion event and then fill HPI event optional data with current >> state. > > I can see how that can make things work for a number of sensors. The > only foolproof solution, I suppose, would be to do some sort of polling > of sensors that don't have deassertion events enabled. It's good to > understand how it works today - this isn't a big deal; I was just trying > to understand the big picture and it confused me. OK. And this polling, I think, shall be plug-in internal affair. > > ===== > > On the DRT, I'll need to dig in a little more and think about this. It > seems that a lot of effort has gone into making things work in a way > where the daemon doesn't need to know what its domain Id is. I don't > quite see what the benefit of that is, but I'm not sure that it makes > sense to carry that philosophy into the DRTs. > > I guess you could define some sort of translation tables in the client > libraries, so that each library instance could have its own different > mapping of domain Ids to daemon IP addresses. You'd have a notion of > "global" domain Ids that live in the daemon DRT tables, and > library-specific domain Ids that are understood by the users, with the > library module translating the domainIds in all DRTs and a few other > places (like announcements) where you can have "foreign" domain Ids > reported. > > But why go to all that trouble? > > HPI requires that domain Ids are unique system wide, so why not just let > them be. Assume that all clients will map the same domain Ids to the > same daemons, so that DRT entries can just hold the correct global > domainIds, and thus need no translation. I would say that the initial > contents of each domain's DRT should be configurable in the openhpi.conf > file used for that daemon. And then, if there is an intelligent plugin > that has a reason to update the DRT dynamically, it can. And, we ought > to be able to assume that if such a plug-in is written, it will be > designed in a way that makes sense for systems where that plugin is > used. Most likely, it would be part of the configuration data provided > to the plugin handler to define how it deals with DRT updates. I think > the details would be plugin-specific. > > My thinking is that library modules should not have anything to do with > DRTs. The mapping of domain Ids to daemon IP addresses that the library > needs is just that - a mapping. And, as mentioned above, it should be > consistent for all clients. (Different clients could potentially have > different default domains, but the mapping of "hard" domain Ids to > daemons should be consistent.) > > I think it would also be nice to add a configuration item to the > openhpi.conf file to tell the daemon what its domain Id is. This could > be done in a backwards compatible way - make this an optional > configuration item; if it is not included, keep using domain Id "0" as > today, with translation in the client. Reserve domain Id "0" for this > purpose, but let it be configured to any non-zero value (except > 0xffffffff, which is SAHPI_UNSPECIFIED_DOMAIN_ID, and does not make > sense as an actual domain Id). > > If configured, then there can be a check to make sure the mapping files > in the client match the domain Id configuration in the daemons (as part > of the saHpiSessionOpen() processing), and the daemon can include its > real domain Id in messages to the client. The client would still > translate domain Ids of "0" received, but would not translate non-zero > domain Ids. > > By making domain Ids more strongly (and statically) associated with > daemons, the decision about what domain Ids should be in what DRTs > becomes something for the system integrator to configure on a > system-wide basis. > > Anyway, that's some early thinking on the subject . . . . Sounds persuasive. :) My argument is it is good to have single place where all domain ids are configured. Configuring them in different systems, in different files and maintaining them could be nightmare. For example ATCA shelf can have up to 16 boards which can have up to 8 AMC Modules. So potentially we can have 129 (+ one for ShMM) HPI servers. As for connectivity parameters for HPI server, may be plug-in can help the Base Library to know board IP addresses dynamically somehow. > > By the way, I've also noticed that there is already some level of > support for DRTs in the code base. I'll keep studying on that, too. Yes, that code worked before OpenHPI-2.10. Since that time nobody used it. > > Regards, > > David > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > Openhpi-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openhpi-devel ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Openhpi-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openhpi-devel
