Design issues with thread-stack isolation/sharing.

[Utkarsh Rai]

This thread is an attempt to consolidate and resolve all the issues that
have been raised related to my patches- 1.
https://lists.rtems.org/pipermail/devel/2020-July/060675.html and 2.
https://lists.rtems.org/pipermail/devel/2020-July/061056.html. I intend to
first resolve all the issues through this thread( and probably convert this
into a blog-post ), before making any further changes.

1. Stack address name that needs to be passed to shm_open() - This was
briefly discussed here
<https://lists.rtems.org/pipermail/devel/2020-July/060536.html>, and I
believe the reason we still have issues with this is because of my
incorrect interpretation of what was suggested. My idea was that we need to
assign a name like "/taskfs/pid" to each stack address on the creation of
the thread. On looking around further, I realize we can have the stack
address name the same as the thread name.

2. Switching out shared stacks- In my current implementation, removing
protected stacks is done through assembly code
<https://github.com/ur10/rtems/blob/stack-sharing/cpukit/score/cpu/arm/cpu_asm.S#L69>
but the '_Stackprotection_Context_switch' which switches out the shared
stack is difficult to implement in assembly. But we need to integrate the
shared stack switching in the context switching code as we don't have
access to executing thread attributes anywhere else.

3. Integration of the 'Stackprotection_attr' structure with the thread and
stack control structure - The integration is a pretty straightforward task,
the difficulty lies in handling the attribute offset in the assembly code,
whereas having the 'Stackprotection_attr'  just after the context control
attribute in the thread control structure makes handling the offset
relatively easy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200801/f7af95f9/attachment.html>