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

[Joel Sherrill]

On Sun, Sep 13, 2020 at 3:41 AM Sebastian Huber <
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.

--joel

>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200913/5ee1217f/attachment.html>