Skip to main content

Monitor Application and CDL

4 replies [Last post]
mattsiw
Offline
Joined: 2010-08-03
Points: 0

I know CDL is currently not fully supported in RI 1.1.4.

From the HOST ATP D11 TC144.1, "in the event that the monitor application is not available, the 'Download Now' scenario shall apply." Is there an api available I can call from the mpe/os porting layer to check to see if the monitor application is up and running?

Is there a way for me to notify the monitor app or java app from the mpe/os porting layer, that a pending 'Deferred Download' CVT request has come in? Then after the deferral period, the monitor app can call the host.java::codeDownload() routine?

I see in DownloadManagerImpl.java, there is a asyncEvent callback function that is called from MPE to indicate an asynchronous Common Download event. It takes a typeCode as a parameter. Do I just call mpeos_eventQueueSend() and send to the event queue registered with the CDL mgr a deferred download event code? Or is more support needed in the RI stack for me to perform a deferred download.

Reply viewing options

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

I think you mostly have the correct behavior in mind.

In your MPEOS CDL port (in the mpeos_cdl.c module), you need to implement the APIs there to allow Java to register/unregister an event queue. When you receive a CVT (or when you want to simulate the receipt of a CVT), send an event to the registered event queue (with event ID in the range defined in org.ocap.system.event.SystemEvent.BEGIN_SYS_DNLD_EVENT_TYPES/END_SYS_DNLD_EVENT_TYPES). The Java layer will receive that event, translate it into a SystemEvent and send that off to the monapp. If NO monapp has registered an event listener, Java will immediately call back down to MPEOS (mpeos_cdlStartDownload) to initiate the immediate download. If there IS a monapp registered to receive the event, download will not occur until the monapp calls Host.codeDownload(), which will call mpeos_cdlStartDownload().

G

mattsiw
Offline
Joined: 2010-08-03
Points: 0

Thanks for the reply Greg. I question however, if deferred download is fully supported in 1.1.4-relB. Here are the reasons for my suspicion.

DownloadManagerImpl.java takes my async event I send from mpeos_cdl and requests the DeferredDownloadEvent with the event code I pass in.
1) There aren't any DeferredDownloadEvent type codes defined for me to use in mpe_cdl.h that map to anything in org.ocap.system.event.SystemEvent.BEGIN_SYS_DNLD_EVENT_TYPES/END_SYS_DNLD_EVENT_TYPES). The only one available to use that I see is to shutdown the event queue.
2) In SystemEvent.java, I see the checkTypeCode() method that mentions it can be overridden by a sub-class. The SystemEvent::checkTypeCode() only range checks event types used in the ErrorEvent class. I don't see this checkTypeCode() method in ErrorEvent, DeferredDownloadEvent, or RebootEvent classes. It looks like SystemEvent is range checking ErrorEvent ranges that should have been handled in the ErrorEvent class.

I don't think I'll be able to just create a new event code. Wouldn't there need to be some form of synchronization with the DeferredDownloadEvent type code with the monitor app and the java app that will notify the monitor app to defer the download?

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

The OCAP spec does not define any specific event types for code download -- just a range of events. The following language appears in the Javadoc for org.ocap.system.event.SystemEvent:

"The event type code is defined with ranges reserved for specific types of events. Ranges defined for the implementation using "SYS" cannot be used by applications.
Ranges defined as "reserved" will be allocated by OCAP (or other future standards). Applications and OCAP implementations SHOULD NOT use these values until their meaning is standardized."

So, I mispoke a little in my first comment. It doesn't matter what you pass as the event code in your MPEOS implementation. If the RI chose to utilize specific type codes to vary our behavior somehow, we could -- but we don't. So, you can pass any integer that you want as long as it is in the range of allowed values (and not the RI-specific SHUTDOWN event). Our implementation doesn't even look at it.

I'm not sure why our subclasses of SystemEvent do not implement the checkTypeCode() method. I'll look into that. Does that all make sense?

G

mattsiw
Offline
Joined: 2010-08-03
Points: 0

Yes, it all makes sense. Thanks for all of your help.