Description Charles Rivet 2015-05-27 15:20:10 EDT

History from ZSBug 1:

--------------------------------------------------
 Barry Maher 2014-08-04 10:59:24 EDT

The configuration parameters (such as system message pool size and default
payload size) need to be run-time configured.

A means of extracting the run-time configuration needs to be devised.

--------------------------------------------------
[reply] [-] Comment 1 Andrew Eidsness 2014-08-04 20:14:43 EDT

Why must the parameters be runtime?  Are there places for configuration that
are not stored in the model?

--------------------------------------------------
[reply] [-] Comment 2 Barry Maher 2014-08-05 12:21:58 EDT

(In reply to comment #1)
> Why must the parameters be runtime?  Are there places for configuration that
> are not stored in the model?

The RTS library is compiled with no knowledge of user configuration parameters.

The configuration may be compiled into the model, but must be determined by the
library at run-time.

--------------------------------------------------
[reply] [-] Comment 3 Andrew Eidsness 2014-08-05 20:40:07 EDT

Ok, that makes sense.  So one possible method for runtime config would be
functions called from generated code?

--------------------------------------------------
[reply] [-] Comment 4 Barry Maher 2014-08-05 22:04:51 EDT

Perhaps the user config parameters have to be pushed to the library via a call
to a library API which sets them.

If the library relies on external symbols (callbacks) to fetch configuration
parameters (i.e. generated by the model) then the library would generate
undefined symbols for users linking in the library that didn't have the
callbacks defined in their code.

On the one hand, perhaps it makes no sense to link in the library without also
setting those user parameters, in which case forcing the user to provide the
callback may make sense.

On the other hand, if we can imagine an app that can make use of the library
without using those parts of the library that need user configuration values,
then we want to let them link in the library without having to provide a dummy
API to resolve an undefined, etc.

I don't know enough at this point to be able to make a definitive call on that.

--------------------------------------------------
[reply] [-] Comment 5 Barry Maher 2014-11-20 16:53:24 EST

There are hard-coded values for pool-sizes, for example, that cannot be
compiled into the RTS library and need to be obtained at run-time.
Code-gen must someone get those values into their code.
Now, we solve it by either
1)    Pushing the values from code-gen to RTS library during startup (using
defaults if they are not yet pushed in).
-- look at thread map file. Should do something similar until tooling is
available.
2)    Pulling the values into RTS library by calling something in code-gen.
If we adopt (2), then the RTS library has a link-time dependency on code-gen.
That means a user linking in the RTS will get an undefined symbol if they pull
in the module that calls code-gen and the user doesn’t have that symbol that
RTS is calling from code-gen.
If we adopt (1), then the RTS library can always be linked against whatever
modules the user supplies and there will be no link-time dependencies.
Examples include the size of the signal pool, the size of the message pool, the
size of the dynamic capsule descriptor pool, the size of the timer pool, and
the number of new elements that should be added to each of these when they
deplete – see also Bug 21.
Priority:  Med, V1

--------------------------------------------------
[reply] [-] Comment 6 Barry Maher 2014-12-02 10:46:22 EST

Users should potentially be permitted to assign thread-priorities to the
controllers.

Since platforms differ in this respect, I think a generic way to specify
thread-priorities should be specified from a user-standpoint and the RTS
platform-specific implementation will morph those into platform-specific
values.

This idea may have been discussed in the context of the 'Top.controllers' file
which assigns controller threads to capsules.

--------------------------------------------------
[reply] [-] Comment 7 Charles Rivet 2014-12-08 12:58:10 EST

(In reply to comment #0)
> The configuration parameters (such as system message pool size and default
> payload size) need to be run-time configured.
> 
> A means of extracting the run-time configuration needs to be devised.

According to Ericsson's Andreas Henriksson, none of these need to be configured
at runtime. It should, however, be possible to define overrides (e.g.,
extension point for modifying) to the default that would be then necessitate a
re-build of the RTS to generate a specific library. These override values
should not be stored in or modifiable from the model. This is a capability that
should not be accessible by model developers as part of their work.

--------------------------------------------------
[reply] [-] Comment 8 Charles Rivet 2014-12-08 13:05:05 EST

(In reply to comment #6)
> Users should potentially be permitted to assign thread-priorities to the
> controllers.
> 
> Since platforms differ in this respect, I think a generic way to specify
> thread-priorities should be specified from a user-standpoint and the RTS
> platform-specific implementation will morph those into platform-specific
> values.
> 
> This idea may have been discussed in the context of the 'Top.controllers' file
> which assigns controller threads to capsules.

Correct, this should also be part of the thread definition that would be part
of the assignment/mapping work being done (and currently implemented in the
'Top.controllers' file). This will need to be coordinated with the UI team. For
now, a set of "standardized", platform-agnostic priorities should be defined.

There was also a discussion about the ability to dynamically change the
priority of a thread (controller) at runtime - formal requirement still TBD...

--------------------------------------------------
[reply] [-] Comment 9 Barry Maher 2015-05-27 14:39:57 EDT

The current version of the RTS uses a single header file (umlrtuconfig.hh) to
obtain the compile-time user-defined configuration parameters.

There are currently 7 values:
USER_CONFIG_SIGNAL_DEFAULT_PAYLOAD_SIZE
USER_CONFIG_MESSAGE_POOL_SIZE
USER_CONFIG_SIGNAL_ELEMENT_POOL_SIZE
USER_CONFIG_TIMER_POOL_SIZE
USER_CONFIG_MESSAGE_POOL_INCR
USER_CONFIG_SIGNAL_ELEMENT_POOL_INCR
USER_CONFIG_TIMER_POOL_INCR

Any mechanism used to allow the user to change these values is outside of the
scope of the RTS and would have to be implemented by code generation and/or
Papyrus.

A new bug on eclipse.org should be raised against the associated component if
user support for modifying these (or any other) configuration parameters needs
to be added.

--------------------------------------------------
 Charles Rivet 2015-05-27 15:17:33 EDT

Actually, this should be moved to the Eclipse Bugzilla and closed as such.

"Modele Developer" users should not be permitted to change those values (as per
comment 7), only "RTS Toolsmith" users acting on behalf of the project
architect.