[PATCH v2] rtems: Add rtems_task_create_from_config()
sebastian.huber at embedded-brains.de
Thu Sep 3 12:08:25 UTC 2020
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
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:
This involves a unification/consolidation of the Doxgyen and Sphinx
Afterwards I would like to concentrate more on higher level aspects
which cover more than one directive.
More information about the devel