<div dir="ltr"><div dir="ltr"> This has gotten to be a long-ish side discussion. I havecomments on the patch and will reply to the original email for that. <br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 3, 2020 at 10:17 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/9/20 10:08 pm, Sebastian Huber wrote:<br>
> <br>
> On 03/09/2020 04:08, Chris Johns wrote:<br>
>> On 3/9/20 2:09 am, Sebastian Huber wrote:<br>
>>> In contrast to rtems_task_create() this function creates a task with a<br>
>>> user-provided task storage area. The new create function uses a<br>
>>> configuration structure instead of individual parameters.<br>
>>><br>
>>> Add RTEMS_TASK_STORAGE_ALIGNMENT to define the recommended alignment of<br>
>>> a task storage area.<br>
>>><br>
>>> Add RTEMS_TASK_STORAGE_SIZE() to calculate the recommended size of a<br>
>>> task storage area based on the task attributes and the size dedicated to<br>
>>> the task stack and thread-local storage. This macro may allow future<br>
>>> extensions without breaking the API.<br>
>> Have all the issues in the other thread been resolved? It would be good to have<br>
>> Joel ack this patch before it is merged.<br>
> I tried to address the issues raised by Joel.<br>
<br>
He will need to answer.<br></blockquote><div><br></div><div>I will also comment on the patch. But the first thing I noticed was how does the user </div><div>know the amount of memory required for keys? That was in a Doxygen comment </div><div>about the macro which is a big improvement but still makes the user guess</div><div>something we should compute.</div><div><br></div><div>This reminds me of not giving an option to account for message buffers. Then</div><div>we added a confdefs macro to specify the total amount of memory. It took another</div><div>release before we realized that we didn't give the user a way to calculate the</div><div>memory required per queue based on number of messages and size of the </div><div>buffer. This made them guess to account for the overhead for each of those.</div><div>Let's try to avoid making users guess the size of memory that we would normally</div><div>compute.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>> In considering the support for static allocation in general I am wondering if<br>
>> the RTEMS Classic API Guide is poorly named? This is a new API with new features<br>
>> and it is not "classic". The Key Concepts section of the that manual says...<br>
>><br>
>> "RTEMS provides directives which can be used to dynamically<br>
>> create, delete, and manipulate a set of predefined object types."<br>
>><br>
>> This change makes this statement questionable.<br>
> <br>
> The task is still dynamically created, however, with a user-provided task<br>
> storage area. It is similar to the POSIX threads which also have to option to<br>
> use a user-provided task storage area. When you don't use unlimited objects,<br>
> then the memory for task control blocks is only statically allocated. The tasks<br>
> are dynamically maintained.<br>
<br>
Thanks. This makes sense and almost what could be used in the documentation :)<br></blockquote><div><br></div><div>We just need to make sure we name the various situations clearly without names</div><div>like new/old, improved, etc. </div><div><br></div><div>I see a handful of RTOS memory organizations a systems designer has to pick</div><div>and we have to name and explain them.</div><div><br></div><div>(1) Workspace vs C Program Heap</div><div> - usually associated with hard limits on objects. Unlimited is of marginal</div><div> use with the split memory model.</div><div><br></div><div><div>(2) Unified Workspace/Heap<br></div><div> - usually associated with unlimited objects</div><div><br></div><div>On top of that, you have </div></div><div><br></div><div> (a) stack and FP allocated from Workspace</div><div> (b) BSP/application provided stack allocator</div><div> (c) Application provided memory per task</div><div><br></div><div>That makes six combinations. I would tend to say that if you choose to</div><div>use Unified Workspace, then 2a makes sense. 2b also makes sense if</div><div>you had some stack protection scheme. But why would someone mix in</div><div>2c. Should work but not likely to be a common setup unless we do it</div><div>in support code.</div><div><br></div><div>For (1), I can see situations where you would use 1a, 1b, and 1c. </div><div><br></div><div>Overall, I see a-c as useful with 1+2 and a-c should work with 1 or 2</div><div>but we have to explain the choices. </div><div><br></div><div>I think this means we need to name a-c so we use consistent </div><div>terms across the community.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> The self-contained synchronization objects of this chapter<br>
> <br>
> <a href="https://docs.rtems.org/branches/master/c-user/self_contained_objects.html" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/c-user/self_contained_objects.html</a><br>
> <br>
> are a different kind of thing.<br>
<br>
Yes and this makes the word Classic look wrong.<br></blockquote><div><br></div><div>Classic is probably technically only the core APIs that derived from RTEID/ORKID</div><div>or soon thereafter. Perhaps only the managers that existed before any POSIX was</div><div>added which would be strictly less than v4.x of RTEMS.</div><div><br></div><div>But now, Classic is just RTEMS specific APIs that start with rtems_ even though that</div><div>leads to duplicate functionality between Classic proper and the self contained objects.</div><div><br></div><div>I think this is just a matter of naming chapters correctly and ensuring that the</div><div>first 2 sentences of each self-contained object type's description makes it clear</div><div>the distinction.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
>> I am sure there are other places<br>
>> that will need to be updated. What documentation and examples are planned to<br>
>> explain the different allocation models RTEMS now supports? I think we have 3<br>
>> APIs and the "Classic" API now has 2 allocation models. I fine with the<br>
>> expansion of the ways RTEMS can be used but we need to make sure we explain<br>
>> these differing ways, why they exist, and the advantages and disadvantages. I<br>
>> would prefer we not leave this as an exercise for the users to do by reading<br>
>> header files.<br>
> <br>
> Yes, we need some guidance for the users. I will definitely work on<br>
> documentation updates. I would like to work first on the specification of the<br>
> Classic API directives:<br>
> <br>
> <a href="https://devel.rtems.org/ticket/3993" rel="noreferrer" target="_blank">https://devel.rtems.org/ticket/3993</a><br>
> <br>
> This involves a unification/consolidation of the Doxgyen and Sphinx documentation.<br></blockquote><div><br></div><div>OK. </div><div><br></div><div>FWIW I also think the rationale for picking a scheduling algorithm is a challenge</div><div>and similar in that we have multiple options for a very high level systems </div><div>design decision. Questions like OS memory allocation scheme, scheduler</div><div>selection, and API selection need to be addressed somewhere. The first two</div><div>fit into the Classic API Guide (which used to be the Users Guide so could be</div><div>renamed again). But selecting an API is a bit different in that you are already</div><div>down a design level when in this manual. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> Afterwards I would like to concentrate more on higher level aspects which cover<br>
> more than one directive.<br>
> <br>
<br>
Excellent and thanks. The question is about the plan not the timeline.<br></blockquote><div><br></div><div>+1 </div><div><br></div><div>I'm not opposed in principle. I am just leary of adding anything that does </div><div>not present a clear definition to the user and has a well-defined purpose.</div><div>You added some concepts that need to be accounted for as design</div><div>variations and the APIs need to be solid.</div><div><br></div><div>--joel </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Chris<br>
</blockquote></div></div>