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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
