[PATCH v2] rtems: Add rtems_task_create_from_config()

[Chris Johns]

On 3/9/20 10:08 pm, Sebastian Huber wrote:
> 
> 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.

He will need to answer.

>> 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.

Thanks. This makes sense and almost what could be used in the documentation :)

> 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.

Yes and this makes the word Classic look wrong.

>> 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.
> 

Excellent and thanks. The question is about the plan not the timeline.

Chris