[PATCH v2] Strict thread-stack isolation

[Gedare Bloom]

>> > diff --git a/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h b/bsps/arm/include/bsp/arm-cp15-set-ttb-entries.h
>> > new file mode 100644
>> > index 0000000000..e69de29bb2
>> > diff --git a/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
>> > new file mode 100644
>> > index 0000000000..0c82f113a9
>> > --- /dev/null
>> > +++ b/bsps/arm/xilinx-zynq/mmu/bsp-set-mmu-attr.c
>> > @@ -0,0 +1,79 @@
>> > +#include <bsp/arm-cp15-start.h>
>> > +#include <rtems/score/memorymanagement.h>
>> > +#include <libcpu/arm-cp15.h>
>> > +#include <rtems.h>
>> > +
>>
>> This could use a comment why it is necessary. And also a note about
>> converting to a configuration option
>> > +#ifdef USE_THREAD_STACK_PROTECTION
>> > +  #define ARM_MMU_USE_SMALL_PAGES
>> > +#endif
>> > +
>>
>> Although it is not strictly required to have doxygen in the BSPs, I
>> would like to see some function documentation of this new interface.
>> > +void Memorymanagement_Set_entries(uintptr_t begin, size_t size, Memorymanagement_flags flags)
>>
>> I don't like the namespace choice. Did you discuss this with anyone?
>>
>> The naming rules are in
>> https://docs.rtems.org/branches/master/eng/coding-naming.html
>>
>> I guess we haven't codified the BSP interface rules. You might inquire
>> in a separate thread for some discussion. From what I recall, we have
>> bsp_* for some generic kind of functions that should be implemented by
>> bsp. So if this is meant to be a BSP implemented interface, you might
>> like "bsp_memory_management" or some such.
>>
>>
>> Memory management might be an overloaded term that could encompass
>> allocation/deallocation, sharing, protection, translation/virtual
>> memory, maybe more. If allocation is not in scope, then some other
>> name might be better. I guess you may be inspired by MMU.  If the
>> point of this interface is to manipulate the mmu/mpu hardware then the
>> name should reflect that. I know we've had these discussions in the
>> past, every time a student works on this topic--did you look for/find
>> any prior discussion or interface descriptions?
>>
>
> As you suggested earlier, maybe this can be modeled along the lines of the cache manager?
> Maybe 'rtems_memory_protection_xx_xx'  is a good naming pattern (This will be moved to cpukit/include/rtems)?
>

It depends on whether we really need to expose a runtime interface for
this stuff to users. I'm not convinced that is necessary yet. Not if
we can make most of it work through the configuration space, and
perhaps through existing interfaces like shm and mmap.

We might consider whether runtime changes can be supported through
extending the existing interfaces for task management.

-Gedare