On 11/30/2016 10:42 AM, Ronny Meeus wrote:
> In the pSOS interface region 0 can be used by applications to allocate
> memory from. It contains 'system' memory and is created by default during
> system init. Region 0 is currently not supported by the xenomai psos skin.
> This patch adds functionality to configure a 'pseudo 0' region that will
> be used if applications allocate memory from region 0.
> To enable this, following code needs to be added to the early application
> init code to configure region 0 (before applications use rn_getseg(0,...)).
> unsigned long rnid,rsize;
> unsigned long rn_0_size = 128000;
> unsigned long unit_size = 128;
> rn_create("_RN0",malloc(rn_0_size),rn_0_size, unit_size, 0, &rnid, &rsize);
> diff --git a/include/psos/psos.h b/include/psos/psos.h
> --- a/include/psos/psos.h
> +++ b/include/psos/psos.h
> @@ -253,6 +253,8 @@ u_long q_vbroadcast(u_long qid,
> u_long msglen,
> u_long *count_r);
> +void set_pseudo_rn0_id(unsigned long id);
I'm fine with the reason to add support for RN#0, not with the way you
do it. The proper logic would rather be:
- define proper tunable psos_rn0_size representing the size of RN#0,
defaulting to 0 bytes
- create RN#0 from psos_init() if psos_rn0_size is non-zero
That would address several issues:
- eliminate the quite ugly remapping from 0 to some pseudo rnid
- keep the tunable bits in the emulator core (this stuff is no
application's business in the Xenomai model).
- allow pulling memory from RN#0 from static C++ ctors and other library
init code which may run before the application entry point is reached.
The application would only have to call
set_config_tunable(psos_rn0_size, <size>) from a setup() handler, as
documented here (likewise for the unit size):
Xenomai mailing list