#1671 At daemon initialization, users may get incomplete data
When the daemon is initializing, at least with the ipmidirect plugin, there exists a window when a user can open a session successfully, but the RPT, and probably other tables in the domain are not yet populated. Calling saHpiDiscover() immediately after saHpiSessionOpen() is a workaround for this problem, but the HPI specification says explicitly that it shall not be required to call saHpiDiscover() to see the tables populated.
Either the daemon should not accept open sessions until the RPT and other tables are populated at initialization, or the functions that query these tables for the user must know that they are not yet initialized, so that the data can be fetched just-in-time if requested. Probably just delying the accepting of new sessions until the initialization is really complete is the easiest.
It is not clear whether this is a problem in the plug-in or the main daemon code, but I have only seen it with the ipmidirect plugin.
What do you think about making saHpiDiscover an async call?
For example it will return "IN_PROGRESS" error code immediately.
It is not clear why we should block session opening until discovery is done. New hardware and new plug-ins can be added during run time. HPI app may subscribe to events and will see managed system changes.
However there is a gap between saHpiSessionOpen and saHpiSubscribe where some event can be lost.
David shared the following comments 3 or 4 days ago. Thank you.
This is has been a pet-peeve of mine in the OpenHPI implementation from the beginning. However, the "workaround" to this problem, immediately following a call to saHpiSessionOpen() with a call to saHpiDiscover() has become so entrenched through the years, that fixing the OpenHpi implementation to work the way the HPI specification says it should work, at this point, is not likely to be worth any amount of effort - and it could be quite a bit of effort to fix.
With the ipmidirect plugin, the workaround is not a problem, because a call to saHpiDiscover() is very low cost unless it blocks waiting on initialization to complete. The reason that this bugs me is that a user should not need to know what the implementation does in order to write code that uses HPI. If an HPI implementation does what it is supposed to do when a call is made to saHpiDiscover() (as opposed to what OpenHPI, at least with the ipmidirect plugin does), then saHpiDiscover() would be an expensive operation, and not something that users would want to routinely do after every call to saHpiSessionOpen().
But, as I said - this is pretty much water under the bridge at this point. Everybody just routinely calls saHpiDiscover() after saHpiSessionOpen(), because that's what you have to do with OpenHPI. So, I don't realistically see this getting changed at this late date.
I would advise against making saHpiDiscover() async, as there is a lot of software out there that depends on it being a blocking call. If there was a need for an async version of saHpiDiscover(), it probably should be created as a new function. But, I don't see any big pull for such a function.
On the philosophical front, there should definitely be a way for a user to know that initialization has completed before doing other operations. Having saHpiSessionOpen() followed by saHpiDiscover() do that is not how the spec says it should work, but OpenHPI has acted that way for many years, so it doesn't seem to be a big issue in the real world.
Changing things so that a user did not have an easy way to know that they are connected to a fully-initialized daemon would not be an improvement.