On Sun, Aug 30, 2020 at 8:50 AM Sebastian Huber <sebastian.hu...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
