SDRP — Port related interfaces

I have been reviewing the Port related interfaces in the SWRadio spec following the discussion at the FTF meeting this morning around issues 7578 and 7579.

In doing so, I worked through a scenario which I believe is valid but not supported by the current SWRadio model (it is also broken in SCA 2.2 which is where I first ran into it). Perhaps we could discuss this in tomorrow mornings session to determine if the spec is deficient (or else my understanding of it is). If so then a new issue may be needed. Here is a synopsis:

Issue 7578 notes that a "provided port can have multiple interfaces" and proposes the addition of a parameter to the PortSupplier::getPort (possibly to be renamed as suggested this morning) operation to select the required interface. Agreed, however I believe it is also possible that a Resource (particularly a DeviceComponent) may need to expose multiple instances of a particular provides Port and need a way to distinguish between these also.

Let me try to explain what I mean using a concrete example:

Consider an ExecutableDeviceComponent which represents a physical processor containing a set of hardware resources (watchdog timers perhaps) managed as a capacity, and which provides a Port interface to access each of these hardware resources. An Application may deploy Components on the ExecutableDevice (by specifying capacity allocations for one or more of the hardware resources) and connect them to it the provides Port on the Device (by means of devicethatloadedthiscomponentref). The Application may intend to connect each Component to the same Port instance (i.e. to the same hardware resource) or it may want to connect each to a different instance, or some combination of the two. Moreover, it is possible that another Application may be deployed and need be to connect to a unique Device Port instance(s). The Device however, has no way of distinguishing between multiple calls to the getPort operation requesting the same instance of the Port, and multiple calls requesting different instances of the Port.

(Note that on the Uses Port side, the PortConnector::connectPort/disconnectPort does not seem to suffer from the same problem since the connectionID parameter may be used to identify a particular instance).

I could not find a way to support this scenario using the current spec. I tried using a Device per hardware resource but these need to be somehow tied to the parent ExecutableDevice. I also tried saying that this is an application level problem but I don't believe the application can solve the this entirely by itself.

A possible solution:
Add an instanceID parameter to the getPort operation (this would need to be a combination of an Application unique ID and a port instance ID).

Related problems:
1. How does an applications profile (SAD) indicate: "multiple connections to the same Port instance, multiple connections to unique Port instances, or some combination of the two."

2. The above solution implies a need to "un-get" a Port (so that it may be reused). Is another operation required? Or perhaps there needs to be a way to (optionally) tie a Port to a capacity allocation/deallocation.

No Data Available