[PATCH v2] rtems: Add rtems_task_create_from_config()

[Chris Johns]

On 9/9/20 8:43 am, Joel Sherrill wrote:
> On Wed, Sep 2, 2020 at 11:09 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de <mailto:sebastian.huber at embedded-brains.de>>
> wrote:
>     +/**
>     + * @brief Returns the recommended task storage area size for the specified size
>     + *   and task attributes.
>     + *
>     + * @param _size is the size dedicated to the task stack and thread-local
>     + *   storage.
> 
> How does the user get the TLS size? 
> 
> Need advice on that. Seems hard to get at compile time since it is a link
> time aggregation. 

I had not noticed this. Thank you for raising it.

Does the API call check this new size value against the size actually needed?

I thought the TLS size was set by the linker based on the declared TLS variables
in the code and that value is feed into the calculation of the memory when
dynamically allocating the task's space. I am now wondering if this is accounted
for if the allocation is from the workspace (sizeof(TLS) * tasks)? A linker
controlled size is fine for the statically linked only class of application
however it is broken for applications that dynamically load code with TLS
variables. There is a growing number of important applications dynamically
loading code so we need to consider it.

I would like to see us resolve how we manage TLS allocation for this case and
dynamic loading before I am OK with this change. I do not think it is fair to
have dynamic loading fit in or work around a change in this area.

FreeBSD and Linux dynamically allocate the TLS blocks and Linux resizes the
blocks when dynamically loaded code contains TLS variables. That approach is not
as easy on RTEMS for a range of reasons that are not important here.

A single allocation for all the data a task needs is attractive. It allows this
API to work and it saves the heap block overheads when using an allocator. It
however means the TLS size needs to be set to the maximum for an application
including all dynamically loaded code.

Maybe the ability to set the size in confdefs.h at the system level would be
sufficient. Defining it at the task level is misleading because it implies tasks
can have different TLS sizes and they cannot. A system level TLS size of 0 could
be used to have the linker size be the size used, this would be compatible to
what we currently have. A system level size of 0 for this new API call would be
a fatal error the there are TLS variables.

TLS management in RTEMS is similar to the SDATA area the PowerPC has. The only
difference is the TLS size can be varied and the SDATA size is fixed in
hardware. If a system level TLS size is supported and that value has a suitable
interface libdl can support dynamically loaded TLS variables the same way SDATA
is handled on the PowerPC. Libdl uses a bit-allocator to track 32bit blocks of
SDATA. The statically linked usage is known and initialised and libdl assumes
ownership of the remaining space. The TLS block can be handled the same way. The
RTL lock handles the runtime set up without effecting scheduling and the same
can happen for TLS data.

Chris