OK. Minimum is supposed to be just that. If something is in it which can be trimmed out, it is up for discussion.
This looks good to me. On Thu, Sep 8, 2022 at 9:15 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > The CONFIGURE_UNIFIED_WORK_AREAS option pulls in a system initialization > handler which initializes the unified heap. > > Close #4108. > --- > testsuites/samples/minimum/init.c | 15 --------------- > 1 file changed, 15 deletions(-) > > diff --git a/testsuites/samples/minimum/init.c > b/testsuites/samples/minimum/init.c > index 347b6ce991..ee14a1aef4 100644 > --- a/testsuites/samples/minimum/init.c > +++ b/testsuites/samples/minimum/init.c > @@ -104,21 +104,6 @@ static void *Init( uintptr_t ignored ) > */ > #define CONFIGURE_MAXIMUM_PRIORITY 15 > > -/* > - * This configures RTEMS to use a single memory pool for the RTEMS > Workspace > - * and C Program Heap. If not defined, there will be separate memory > pools > - * for the RTEMS Workspace and C Program Heap. Having separate pools > - * does haved some advantages in the event a task blows a stack or writes > - * outside its memory area. However, in low memory systems the overhead > of > - * the two pools plus the potential for unused memory in either pool is > - * very undesirable. > - * > - * In high memory environments, this is desirable when you want to use > - * the RTEMS "unlimited" objects option. You will be able to create > objects > - * until you run out of memory. > - */ > -#define CONFIGURE_UNIFIED_WORK_AREAS > - > /* > * In this application, the initialization task performs the system > * initialization and then transforms itself into the idle task. > -- > 2.35.3 > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
