On 09/09/2020 00:25, Joel Sherrill wrote:
This has gotten to be a long-ish side discussion. I havecomments on
the patch and will reply to the original email for that.
On Thu, Sep 3, 2020 at 10:17 PM Chris Johns <chr...@rtems.org
<mailto:chr...@rtems.org>> wrote:
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.
I will also comment on the patch. But the first thing I noticed was how
does the user
know the amount of memory required for keys? That was in a Doxygen comment
about the macro which is a big improvement but still makes the user guess
something we should compute.
This reminds me of not giving an option to account for message buffers. Then
we added a confdefs macro to specify the total amount of memory. It took
another
release before we realized that we didn't give the user a way to
calculate the
memory required per queue based on number of messages and size of the
buffer. This made them guess to account for the overhead for each of those.
Let's try to avoid making users guess the size of memory that we would
normally
compute.
The problem is that the TLS size is known at link-time (or even run-time
if you take dynamic linking into account). You can't calculate this at
compile-time.
>> 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 :)
We just need to make sure we name the various situations clearly without
names
like new/old, improved, etc.
I see a handful of RTOS memory organizations a systems designer has to pick
and we have to name and explain them.
(1) Workspace vs C Program Heap
- usually associated with hard limits on objects. Unlimited is of
marginal
use with the split memory model.
(2) Unified Workspace/Heap
- usually associated with unlimited objects
On top of that, you have
(a) stack and FP allocated from Workspace
(b) BSP/application provided stack allocator
(c) Application provided memory per task
That makes six combinations. I would tend to say that if you choose to
use Unified Workspace, then 2a makes sense. 2b also makes sense if
you had some stack protection scheme. But why would someone mix in
2c. Should work but not likely to be a common setup unless we do it
in support code.
For (1), I can see situations where you would use 1a, 1b, and 1c.
Overall, I see a-c as useful with 1+2 and a-c should work with 1 or 2
but we have to explain the choices.
I think this means we need to name a-c so we use consistent
terms across the community.
Yes, this makes sense. Finding good names for a-c will not be easy (at
least for me).
> 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.
Classic is probably technically only the core APIs that derived from
RTEID/ORKID
or soon thereafter. Perhaps only the managers that existed before any
POSIX was
added which would be strictly less than v4.x of RTEMS.
But now, Classic is just RTEMS specific APIs that start with rtems_ even
though that
leads to duplicate functionality between Classic proper and the self
contained objects.
I think this is just a matter of naming chapters correctly and ensuring
that the
first 2 sentences of each self-contained object type's description makes
it clear
the distinction.
Yes for me this manual is for everything which is part of the API and
starts with rtems_*.
>> 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.
OK.
FWIW I also think the rationale for picking a scheduling algorithm is a
challenge
and similar in that we have multiple options for a very high level systems
design decision. Questions like OS memory allocation scheme, scheduler
selection, and API selection need to be addressed somewhere. The first two
fit into the Classic API Guide (which used to be the Users Guide so could be
renamed again). But selecting an API is a bit different in that you are
already
down a design level when in this manual.
>
> 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.
+1
I'm not opposed in principle. I am just leary of adding anything that does
not present a clear definition to the user and has a well-defined purpose.
You added some concepts that need to be accounted for as design
variations and the APIs need to be solid.
Ok, good. I just need some way that enables me to work to step by step.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
