[PATCH v4 2/5] rtems: Add rtems_task_create_from_config()

[Sebastian Huber]

On 13/09/2020 23:17, Joel Sherrill wrote:

>
>
> On Sun, Sep 13, 2020 at 3:41 AM Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at 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.

What about:

CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE

or

CONFIGURE_TASKS_WITH_USER_PROVIDED_STORAGE

I don't like the work maximum for this configuration option. You can 
also create more that this value indicates, however, at the expense of a 
wasted system-provided stack space.

This new name makes the configuration independent of a directive name 
(rtems_task_create_from_config(), rtems_task_build(), rtems_task_make(), 
...). Long but descriptive option names a not really an issue since you 
write them only once in your application.

This new option has the following constraints:

1. CONFIGURE_MINIMUM_TASKS_WITH_USER_PROVIDED_STORAGE <= 
CONFIGURE_MAXIMUM_TASKS

2. The unlimited flag must not be set.