On 3/2/20 4:27 pm, Sebastian Huber wrote: > ----- Am 3. Feb 2020 um 0:01 schrieb Chris Johns chr...@rtems.org: > >> On 3/2/20 12:28 am, Sebastian Huber wrote: >>> This change set reworks the work area initialization carried out by the >>> BSPs to >>> initialize the workspace and C program heap only on demand, e.g. in case >>> these >>> components are used by the application. >>> >>> Currently, the workspace is always used, however, this may change in a >>> follow up >>> change set. >> >> Is the purpose of change to have a more efficient use of the workspace >> because a >> defined area is reserved and allocated when the manager is initialised? > > No, this patch set changes the way how BSPs provide the memory area used for > the workspace and the C program heap. It doesn't change how the workspace > itself is used.
OK and thanks. >> I am not sure what the "demand" is and where it is coming from. > > Currently, the workspace and C program heap area always initialized. With > this patch, they are only initialized if they are used. So, a future > application which only uses statically allocated resources, will not have the > heap handler in its executable. Is the reason why and approach for making a fully static application documented anywhere? How will a user know this exists? I assume this helps low memory targets? >> How are allocation errors handled? Traditionally this has been at compile >> time >> but I am not sure if this is still valid. > > Workspace allocation errors were never handled at compile time, they result > in fatal run time errors or failed directives. This patch set changes nothing > in this respect. Sure. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
