#3621 closed enhancement (fixed)
Statically initialize object information structures
Reported by: | Sebastian Huber | Owned by: | Sebastian Huber |
---|---|---|---|
Priority: | normal | Milestone: | 5.1 |
Component: | score | Version: | 5 |
Severity: | normal | Keywords: | qualification |
Cc: | Blocked By: | ||
Blocking: |
Description
Statically initialize the object information structures to make the configuration easier to review and simplify the debugging.
The workspace size estimate generated by <rtems/confdefs.h> looks currently like this:
const rtems_configuration_table Configuration = { ( ( ( (ssize_t) ((((((1 + 0) != 0 ? 1 : 0) * ((Objects_Maximum) ((1 + 0) & ~0x80000000U))) * (sizeof(Configuration_Thread_control))) != 0 ? 1 : 0) * ((((((1 + 0) != 0 ? 1 : 0) * ((Objects_Maximum) ((1 + 0) & ~0x80000000U))) * (sizeof(Configuration_Thread_control)) + (2 * sizeof(uintptr_t) + (sizeof(Heap_Protection_block_begin) + sizeof(Heap_Protection_block_end)))) + ((((sizeof(Heap_Block)) + (8) - 1) - ((sizeof(Heap_Block)) + (8) - 1) % (8))) - 1) - (((((1 + 0) != 0 ? 1 : 0) * ((Objects_Maximum) ((1 + 0) & ~0x80000000U))) * (sizeof(Configuration_Thread_control)) + (2 * sizeof(uintptr_t) + (sizeof(Heap_Protection_block_begin) + sizeof(Heap_Protection_block_end)))) + ((((sizeof(Heap_Block)) + (8) - 1) - ((sizeof(Heap_Block)) + (8) - 1) % (8)))
[more than 500 similar lines]
1) - (((sizeof(Configuration_Initial_Extensions) / sizeof((Configuration_Initial_Extensions)[0])) * sizeof(User_extensions_Switch_control) + (2 * sizeof(uintptr_t) + (sizeof(Heap_Protection_block_begin) + sizeof(Heap_Protection_block_end)))) + ((((sizeof(Heap_Block)) + (8) - 1) - ((sizeof(Heap_Block)) + (8) - 1) % (8))) - 1) % ((((sizeof(Heap_Block)) + (8) - 1) - ((sizeof(Heap_Block)) + (8) - 1) % (8)))))) + 0 + 0 + (0 * 1024) + ((((2 * sizeof(uintptr_t) + (sizeof(Heap_Protection_block_begin) + sizeof(Heap_Protection_block_end)))) + (8) - 1) - (((2 * sizeof(uintptr_t) + (sizeof(Heap_Protection_block_begin) + sizeof(Heap_Protection_block_end)))) + (8) - 1) % (8)) ),
The object controls reside on the heap even for fixed object count configuration. Using a statically allocated array makes it easier to find the objects during debugging.
Change History (15)
comment:1 Changed on 11/27/18 at 00:53:30 by Chris Johns
comment:2 Changed on 11/27/18 at 06:00:08 by Sebastian Huber
You can still do whatever you want after the system is initialized. I just want to get rid of the workspace allocations used during the system startup and instead use storage allocated by the linker.
comment:12 Changed on 12/14/18 at 06:04:05 by Sebastian Huber <sebastian.huber@…>
In 0f5b2c09/rtems:
comment:13 Changed on 12/14/18 at 06:04:08 by Sebastian Huber <sebastian.huber@…>
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
In 21275b58/rtems:
comment:14 Changed on 01/02/20 at 08:49:12 by Sebastian Huber <sebastian.huber@…>
In a320aedd/rtems:
comment:15 Changed on 06/23/21 at 07:16:03 by Sebastian Huber
Keywords: | qualification added |
---|
Note: See
TracTickets for help on using
tickets.
Replying to Sebastian Huber:
It is not clear me to what the requirements are these change are being based on? Is there some overriding push for everything to be static tables every where.
Static tables for initialisation do solve some issues such as audit-able configuration control but are there other use cases where this may not be a good fit. I cannot tell. For example statically inflexible kernel initialisation and libdl do not sit well together. The demands on the kernel configuration from the loadable code can vary and does and if you consider libdl as a means to produce "golden images" having the ability to vary the configuration is important. I have built systems where the bootloader loads the kernel configuration data and then loads the application. Can this still be done?