Inconsistent relations between devices or processors and subprograms

[buzden]

device and processor component categories are both allowed to have provides subprogram access but are disallowed to have requires subprogram access and even subprogram subcomponents. This seems to be strange and inconsistent.

Regarding to a particular relation between processors and subprograms, generally processor still can provide an access to a subprogram inside a process component which is its subcomponent. But even considering this, a restriction of only providing subprogram accesses doesn't seem very reasonable because of the following.

processor components incapsulate operating systems (besides other functions). Service calls (which are like system calls of OS) are represented with subprograms in the standard. device components incapsulate devices themselves but also drivers (in some variants of modelling, supported by the standard). Device drivers often provide some known interface and are able to use some particular OS interface.

In deep modelling we may want to represent which functionality is bound to which requirements of e.g. device drivers. It seems that subprograms and proper accesses are the best fitting way to model this. But we are allowed neither to define subprograms in processors and devices nor to declare subprogram requirements using requires subprogram accesses.

So, summing up:

• there is an existing construct (provides subprogram access for devices) which cannot be correctly fulfilled in a full AADL-model;
• it seems, there is a need of more flexibility rather than allowing only provides of subprogram accesses for devices and processors.

[reteprelief]

Agreed. Useful to allow requires subprogram access on processor, device, virtual processor.

Is there a need to offer subprogram access for buses and virtual bus (e.g., to represent API)?

[reteprelief]

Useful to specify API for buses and virtual buses (Denis has an example).

[reteprelief]

Memory: again it is useful to allow subprogram access.

[reteprelief]

Get use cases from Denis and then consider as V2.2. errata.

[jjhugues]

No info provided. Consider for v3