I would like to make a clarification request to understand
Just so I can help you get to the bottom of this faster, can you point me to the code that is overloading the POD Ready status?
These are the MPEOS definitions that are being referenced:
MPE_POD_EVENT_READY, /* CableCard inserted and ready for use */
* This structure is the main database container for all of the POD related information.
mpe_Mutex pod_mutex; /* Mutex for synchronous access */
mpe_Bool pod_isPresent; /* POD present flag (possibly not yet initialized). */
mpe_Bool pod_isReady; /* POD present & initialized flag. */
mpe_PODAppInfo *pod_appInfo; /* POD application information. */
mpe_PODFeatures *pod_features; /* POD generic feature list. */
mpe_PODFeatureParams pod_featureParams; /* POD generic feature parameters. */
uint32_t pod_maxElemStreams; /* how many Elementary streams the POD can decode at one time */
uint32_t pod_maxPrograms; /* how many programs the POD can decode at one time */
uint32_t pod_maxTransportStreams; /* how many transport streams the POD can decode at one time */
The MPE layer manages a cache of the information available to applications via the org.ocap.hardware.host.POD APIs. This cache is represented by the mpe_PODDatabase structure you indicated above. There is only a single instance of this cache instantiated at system startup and changes to the cache are made via the MPEOS APIs (mpe_PODDatabase is passed to those APIs).
The MPE_POD_EVENT_READY event should only be sent when the MPEOS porting layer has fully populated the mpe_PODDatabase structure. This includes:
1) Connection to the Application Information resource and exchange of the application_info_req() and application_info_cnf() APDUs
2) Connection to the Generic Feature resource and exchange of all APDUs required to determine the list of supported features and the populate the mpe_PODDatabase with the values of each supported feature.
I believe that much should suffice. In the PC Platform port ($OCAPROOT/mpe/os/RI_Common/mpeos_pod.c), we grab the pointer the mpe_PODDatabase and hold onto it so we can update it when we receive asynchronous notifications from the POD (along with sending any appropriate events)
Thanks Greg. Another clarification:
A new dependency was added in the 1.1.4 release with regards to the “M-Mode Device Capability Discovery” because the stack now tries to manage the Conditional Access resource directly instead of having the platform do the management.
Does this imply that the MPEOS layer needs to now wait for the M-Mode capabilities to be fully discovered before the “POD ready” event is sent?
Would it be possible to add some clarification in the MPEOS header file to clarify the conditions under which the supported events and status should be updated?
How can we prevent the definition of the MPEOS “POD Ready” definition from being changed to include other resources or APDUs in the future?
Good call on the CA session... I missed that one. Actually, I would probably add to my list above by saying:
Once the POD_READY event is sent, the CableCARD stack should be sufficiently initialized such that all of the mpeos_pod* APIs can be called by the stack. This includes opening connections to the SAS, CA, and MMI resources
As far as "preventing" the POD READY definition from being changed. We really can't. If specification changes are introduced, we may have to change the definition. But that information could be conveyed in better documentation as you suggest.
As far getting the documentation in place, that is a whole other topic. All I can suggest to you at this point is to create a bug in IssueTracker and we will get to it when we can.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.