On 03/09/2020 04:08, Chris Johns wrote:
On 3/9/20 2:09 am, Sebastian Huber wrote:
In contrast to rtems_task_create() this function creates a task with a
user-provided task storage area. The new create function uses a
configuration structure instead of individual parameters.
Add RTEMS_TASK_STORAGE_ALIGNMENT to define the recommended alignment of
a task storage area.
Add RTEMS_TASK_STORAGE_SIZE() to calculate the recommended size of a
task storage area based on the task attributes and the size dedicated to
the task stack and thread-local storage. This macro may allow future
extensions without breaking the API.
Have all the issues in the other thread been resolved? It would be good to have
Joel ack this patch before it is merged.
I tried to address the issues raised by Joel.
In considering the support for static allocation in general I am wondering if
the RTEMS Classic API Guide is poorly named? This is a new API with new features
and it is not "classic". The Key Concepts section of the that manual says...
"RTEMS provides directives which can be used to dynamically
create, delete, and manipulate a set of predefined object types."
This change makes this statement questionable.
The task is still dynamically created, however, with a user-provided
task storage area. It is similar to the POSIX threads which also have to
option to use a user-provided task storage area. When you don't use
unlimited objects, then the memory for task control blocks is only
statically allocated. The tasks are dynamically maintained.
The self-contained synchronization objects of this chapter
https://docs.rtems.org/branches/master/c-user/self_contained_objects.html
are a different kind of thing.
I am sure there are other places
that will need to be updated. What documentation and examples are planned to
explain the different allocation models RTEMS now supports? I think we have 3
APIs and the "Classic" API now has 2 allocation models. I fine with the
expansion of the ways RTEMS can be used but we need to make sure we explain
these differing ways, why they exist, and the advantages and disadvantages. I
would prefer we not leave this as an exercise for the users to do by reading
header files.
Yes, we need some guidance for the users. I will definitely work on
documentation updates. I would like to work first on the specification
of the Classic API directives:
https://devel.rtems.org/ticket/3993
This involves a unification/consolidation of the Doxgyen and Sphinx
documentation.
Afterwards I would like to concentrate more on higher level aspects
which cover more than one directive.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
