[PATCH v2] rtems: Add rtems_task_create_from_config()

[Sebastian Huber]

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.