Problem Statement
The problem we are trying to solve is adding Multiple Domain support in OpenHPI. The will allow resources and events to exist in domains other than the default domain.
The reason this support is interesting is that a piece of hardware may want to represent it's component parts as seperate Domains. A good example piece of hardware would be a Bladed Chassis, where a single connection to the CMM provides management for a large number (> 10) blades. The hardware may wish to model this via simple resources, or via domains, however the decision on what is the *correct* system model should be left to the hardware itself.
Top Down Approach
Multiple domain support has been looked at since the beginning of OpenHPI. In most cases a Top Down approach was first considered. This is unworkable because:
- it adds yet another level of configuration hacking for the end user. Honestly, we need to make bring up easier, not more painful.
- it complete disregards the plugin author's ideas of how things should be modeled. This policy should be as close to the hardware as possible (in the hardware would be great.)
- it requires containers for domains be only as small as a handler. For the Bladed Chassis setup above, it completely gets rid of this concept.
While it is simpler to develop, this is the wrong approach. It is worth noting that OpenHPI 0.1 had this concept of oh_zone, which was domains as handlers. After spinning on that for 3 months it was thrown out, as we created a number of scenarios that were impossible to model with that approach.
Bottom Up Approach
If not top down, then bottom up is the other natural way to go with this. In this regard think of domain ids similar to device ids in the Linux Kernel. If you want to use hardware devices, and you aren't already allocated them (i.e. IDE), you need to request an id from the kernel. Once it gives you this back you are then free to use dev nodes with that major number for your device driver.
In OpenHPI this could be accomplished by 2 function calls implemented in the infrastructure that are exported to plugins:
SaHpiDomainIdT oh_request_domain_id(unsigned int handler_id, SaHpiDomainIdT parentid, SaHpiDomainIdT peerid); SaErrorT oh_release_domain_id(unsigned int handler_id, SaHpiDomainIdT did);
The first function is the requests a domain id to be allocated. If peerid is 0, it isn't a peer domain. If parentid is 0, it is a child of DEFAULT_DOMAIN. The domain id is returned to the handler, and it is allowed to then have events with that did set in them.
Infrastructure would keep the table of allowed did for each handler id, and when the event loop is processed it will reject any dids not allowed for each handler. This table will also alow calls like saHpiDiscover to only have to call the appropriate subset of handlers when a domain other than default is called for discovery. Due to the nature of the OpenHPI implementation, Discover called on the DEFAULT_DOMAIN will be equivalent to discover called on all domains.
This will allow arbitrarily complex domain structures, which will be entirely managed by the handlers. If you want that kind of complexity, you can do it yourself very nicely. For those that don't want that, they can just keep writing plugins like they are today.