[PATCH 7/7] rtems: Add rtems_task_build()

[Gedare Bloom]

On Sun, Aug 30, 2020 at 8:50 AM Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
>
> On 22/08/2020 09:49, Chris Johns wrote:
>
> > On 21/8/20 9:51 pm, Sebastian Huber wrote:
> >> In contrast to rtems_task_create() this function creates a task with a
> >> user-provided task storage area.
> > The name is build but it creates a task? I am wondering about
> > rtems_task_create_static or something along this line?
>
> A function to do a static initialization is a contradiction from my
> point of view. Static initialization means for me that you statically
> initialize a data structure and then it is ready to use (it may involve
> a static constructor).
>
> The function builds a task from user-provided (stack, attributes, etc.)
> and system-provided (thread control block) components.
>

yes, as a technical term we usually take "static" to mean something
done at compile/build time.

> >
> >> Close #3959.
> > Sorry, I had not read the ticket's details.
>
> There is a similar ticket for message queues:
>
> https://devel.rtems.org/ticket/4007
>
> >
> > Chris
> >
> >> ---
> >>   cpukit/Makefile.am                     |   1 +
> >>   cpukit/include/rtems/rtems/tasks.h     |  65 ++++++
> >>   cpukit/include/rtems/rtems/tasksimpl.h |  11 +
> >>   cpukit/rtems/src/taskbuild.c           | 273 ++++++++++++++++++++++++
> >>   cpukit/rtems/src/taskcreate.c          | 274 +++++--------------------
> >>   testsuites/sptests/sp01/init.c         |  22 +-
> >>   testsuites/sptests/sp01/sp01.doc       |   1 +
> >>   testsuites/sptests/sp01/system.h       |   2 +-
> >>   8 files changed, 413 insertions(+), 236 deletions(-)
> >>   create mode 100644 cpukit/rtems/src/taskbuild.c
> >>
> >> diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
> >> index bc56822cf8..e382478eac 100644
> >> --- a/cpukit/Makefile.am
> >> +++ b/cpukit/Makefile.am
> >> @@ -785,6 +785,7 @@ librtemscpu_a_SOURCES += rtems/src/statustext.c
> >>   librtemscpu_a_SOURCES += rtems/src/statustoerrno.c
> >>   librtemscpu_a_SOURCES += rtems/src/systemeventreceive.c
> >>   librtemscpu_a_SOURCES += rtems/src/systemeventsend.c
> >> +librtemscpu_a_SOURCES += rtems/src/taskbuild.c
> >>   librtemscpu_a_SOURCES += rtems/src/taskcreate.c
> >>   librtemscpu_a_SOURCES += rtems/src/taskdelete.c
> >>   librtemscpu_a_SOURCES += rtems/src/taskexit.c
> >> diff --git a/cpukit/include/rtems/rtems/tasks.h b/cpukit/include/rtems/rtems/tasks.h
> >> index 12c323e60e..dff811686a 100644
> >> --- a/cpukit/include/rtems/rtems/tasks.h
> >> +++ b/cpukit/include/rtems/rtems/tasks.h
> >> @@ -164,6 +164,71 @@ rtems_status_code rtems_task_create(
> >> [...]
> >> +  /**
> >> +   * @brief This member defines the optional handler to free the task storage
> >> +   *   area.
> >> +   *
> >> +   * It may be NULL.
> >> +   */
> >> +  void ( *storage_free )( void * );
> > Called under what context? What can this call do? For example call the standard
> > heap allocator.
>
> This is a good question.  What about:
>
> @brief This member defines the optional handler to free the task storage
> area.
>
> It is called when the task building aborts due to a failed task create
> extension or the task is deleted. It is called from task context under
> protection of the object allocator lock. It is allowed to call free() in
> this handler.
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel