On Sun, Sep 13, 2020 at 3:41 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> On 12/09/2020 02:53, Chris Johns wrote: > > > On 12/9/20 1:34 am, Sebastian Huber wrote: > >> + * @par Notes > >> + * By default, the calculation for the required memory in the RTEMS > Workspace > >> + * for tasks assumes that all Classic API Tasks are created by > >> + * rtems_task_create(). This configuration option can be used to > reduce the > >> + * required memory for the system-provided task storage areas since > tasks > >> + * created by rtems_task_create_from_config() use a user-provided task > storage > >> + * area. > >> + */ > >> +#define CONFIGURE_TASKS_CREATED_FROM_CONFIG > > The documentation does not deal with 0 the default. It is fair to assume > a > > config that controls allocations for an API is consistent with similar > calls. It > > I set message queues to 0 any create call fails. I needed to check the > patch to > > know if 0 meant you could not create any tasks from a config. > > > > If CONFIGURE_TASKS_CREATED_FROM_CONFIG was added to the configuration > table > > (which I am ok with) the rtems_task_create_from_config() could check for > a > > non-zero value before proceeding. > The tasks created by rtems_task_create_from_config() are normal Classic > API tasks. The only difference is that the thread storage is provided by > the user. If you get the configuration wrong, you just have a wrong > workspace size. There are lots of other ways to get a wrong workspace > size. I am not sure if we really should add extra code just to check > this option and produce more run-time errors. > > > >> +#ifndef CONFIGURE_TASKS_CREATED_FROM_CONFIG > >> + #define CONFIGURE_TASKS_CREATED_FROM_CONFIG 0 > >> +#endif > >> + > >> +#if CONFIGURE_TASKS_CREATED_FROM_CONFIG > CONFIGURE_MAXIMUM_TASKS > >> + #error "CONFIGURE_TASKS_CREATED_FROM_CONFIG shall be less than or > equal to CONFIGURE_MAXIMUM_TASKS" > >> +#endif > >> + > >> #ifndef CONFIGURE_MAXIMUM_POSIX_THREADS > >> #define CONFIGURE_MAXIMUM_POSIX_THREADS 0 > >> #endif > >> diff --git a/cpukit/include/rtems/confdefs/wkspace.h > b/cpukit/include/rtems/confdefs/wkspace.h > >> index de476dbf82..215cdcb141 100644 > >> --- a/cpukit/include/rtems/confdefs/wkspace.h > >> +++ b/cpukit/include/rtems/confdefs/wkspace.h > >> @@ -100,7 +100,9 @@ > >> + _CONFIGURE_POSIX_INIT_THREAD_STACK_EXTRA \ > >> + _CONFIGURE_LIBBLOCK_TASKS_STACK_EXTRA \ > >> + CONFIGURE_EXTRA_TASK_STACKS \ > >> - + rtems_resource_maximum_per_allocation( _CONFIGURE_TASKS ) \ > >> + + rtems_resource_maximum_per_allocation( \ > >> + _CONFIGURE_TASKS - CONFIGURE_TASKS_CREATED_FROM_CONFIG \ > > I am confused by this. Does _CONFIGURE_TASKS have the number of tasks > created > > from config included in it? How was that added in? > > > > I would have assumed I set CONFIGURE_TASKS_CREATED_FROM_CONFIG and that > would be > > added _CONFIGURE_TASKS internally. > > > > Sorry, I think I am not understanding something. > > My proposal is to configure the maximum Classic API tasks as usual: > > #define CONFIGURE_MAXIMUM_TASKS 123 > > Then also define how many are created by rtems_task_create_from_config(): > > #define CONFIGURE_TASKS_CREATED_FROM_CONFIG 42 > > An alternative could be to do something like this: > > #define CONFIGURE_MAXIMUM_TASKS 81 > > #define CONFIGURE_MAXIMUM_TASKS_CREATED_FROM_CONFIG 42 > > However, this has some issues: > > 1. What happens if you use the unlimited option for both? > Make it clear that CONFIGURE_MAXIMUM_TASKS_CREATED_FROM_CONFIG is a subset of CONFIGURE_MAXIMUM_TASKS. CONFIGURE_MAXIMUM_TASKS_CREATED_FROM_CONFIG must be strictly <= CONFIGURE_MAXIMUM_TASKS. CONFIGURE_MAXIMUM_TASKS_CREATED_FROM_CONFIG can't have unlimited set. Check all that from confdefs.h. > > 2. You need extra code to enforce the individual maximum values. > Macros I think. At compile time. > > 3. It suggests that the tasks belong to different APIs or object > classes. This is not the case. > Not if explained well. --joel > > _______________________________________________ > 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
