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". :-) 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. ===== 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 . . . . 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. 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
