Skip to main content

Clarification for mpeos_podReceiveAPDU

8 replies [Last post]
amirn
Offline
Joined: 2009-05-06
Points: 0

mpe_Error mpeos_podReceiveAPDU(uint32_t* sessionId, uint8_t **apdu, int32_t *len)

the mpeos_podReceiveAPDU call passes a pointer to where the APDU pointer is returned.

The way the api is defined requires the pod code to allocate a buffer to hold the APDU and thus return a pointer to pod allocated memory.

The api does not state that the caller is responsible for freeing the memory, nor how the memory should be allocated (malloc, etc).

Should the caller of this API allocate and deallocate the APDU buffer or should the implementation be responsible for it.

If the later case is assumed, shouldn't this API be asynchronous (i.e should it take an event queue argument). Retrieving APDU data from the CableCard *is* an asynchronous process.

Thanks.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mkorzen
Offline
Joined: 2008-03-05
Points: 0

Hi Amir -
Which version of the code are you looking at? Looking at trunk here, it looks like there is already a function that does what you are looking for:

/**
* The mpeos_podReleaseAPDU() function
*
* This will release an APDU retrieved via mpeos_podReceiveAPDU()
*
* @param apdu the APDU pointer retrieved via mpeos_podReceiveAPDU()
* @return Upon successful completion, this function shall return
* <ul>
* <li>     MPE_EINVAL - The apdu pointer was invalid.
* <li>     MPE_SUCCESS - The apdu was successfully deallocated.
* </ul>
*/
mpe_Error mpeos_podReleaseAPDU(uint8_t *apdu);

Best -
Marcin

mmindenhall
Offline
Joined: 2009-03-16
Points: 0

Polycipher's homepage now redirects to CableLabs. Does this mean that CL took over that codebase? If so, can they arrange for it to be contributed to the RI project?

dhooley
Offline
Joined: 2008-04-23
Points: 0

The CANH APIs are not part of OCAP. These APIs form the basis for a downloadable application by which a Monitor Application such as an EPG can access the CA system. The CANH APIs are available only under a special license from CableLabs and are not freely distributable. There is currently no CANH implementation available with the RI open source distribution.

mmillard
Offline
Joined: 2008-11-05
Points: 0

For the Vidiom DCAS project, I had to bring the MEPOS implementation up to compliance with CCIF 2.0, introducing support for asynchronous APDUs. If I remember correctly, the API implementation was responsible for allocating and deallocating the APDU buffers and I did introduce an event queue argument to facilitate the asynchronous requirements (with modifications to the MPE and JNI).

This code did not make it into the RI implementation because it was owned by PolyCipher as part of the Vidiom DCAS Emulator project.

The Power TV simulation for the POD behavior needs to be replaced by an RI Platform implementation. The current Power TV simulation was a quick and dirty port from the enableTV Client Simulator (mostly to support requirements for EAS).

amirn
Offline
Joined: 2009-05-06
Points: 0

So, right now if a vendor wants to port the OCAP-RI to a CCIF-2.0 compliant tru2way device, they have to update the MPE POD interface.

Is there any plan to bring up the OCAP-RI MPE POD interface to CCIF-2.0 compliance?

Thanks.

greg80303
Offline
Joined: 2008-07-03
Points: 0

I believe that this API needs to be updated.

As to your second point about synchronous vs. async -- the com.vidiom.impl.manager.system.SystemModuleMgr expects this API to be synchronous. It creates its own thread to block on this API waiting for the next APDU.

If we keep this behavior (synchronous call), then we need to update this API to return a "handle" of some sort to the MPEOS-managed APDU data. Then, when the caller has copied the data it could call a new API to "release" the APDU data based on the handle.

If we made the APDU eventing asynchronous, we would have to allocate the data at the MPEOS level, attach it to an event, and then make the caller free the data. I'm not a fan of that approach -- I think its is much better to have the same module that allocates the memory, free it as well.

I have created Issue #21 to track this problem.

csweeney
Offline
Joined: 2009-04-11
Points: 0

This is not my area of expertise, but in searching through the codebase I found this:


/**
* The mpeos_podReceiveAPDU() function retrieves the next available APDU from the POD.
*
* @param sessionId is a pointer for returning the associated session Id (i.e. Ocm_Sas_Handle).
* @param apdu the next available APDU from the POD
* @param len the length of the APDU in bytes
* @return Upon successful completion, this function shall return MPE_SUCCESS. Otherwise,
* one of the errors below is returned.
*

    *
  • MPE_ENOMEM - There was insufficient memory available to complete the operation.
    *
  • MPE_EINVAL - One or more parameters were out of range or unuseable.
    *
  • MPE_ENODATA - Indicates that the APDU received is actually the last APDU that
    * failed to be sent.
    *

*/
mpe_Error mpeos_podReceiveAPDU(uint32_t* sessionId, uint8_t **apdu, int32_t *len)
{
mpe_Error ec = (mpe_Error)(-1);
Pk_Event *ev;

/* Check for need to initialize the event queue. Note, no mutex needed since */
/* this routine is only called by a single thread from the java SystemModuleMgr. */
if (NULL == podEvQ)
{



...




Note the comment about being called from SystemModuleMgr.


amirn
Offline
Joined: 2009-05-06
Points: 0

I was looking at that code in mpeos_pod.c.
By the way, this is a PowerTV OS implementation that probably shouldn't be in the RI distribution.

Looks like in that implementation they wait forever on the event indicating new APDU and then extract the data, copy it in the allocated buffer before returning it to the caller.

It is still not clear whether the caller should allocate/deallocate the buffer or this should be done in the implementation.