GSoC: Correct placement and naming of memory protection APIs

[Hesham Almatary]

We have already discussed and done that during my 2013 GSoC. Have a
look at [1, 2] and their calls.

[1] https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/score/include/rtems/score/mmimpl.h
[2] https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/score/include/rtems/score/mm.h

On Fri, 17 Jul 2020 at 21:33, Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>
> Hello,
> In RTEMS each set of BSP has its own MMU implementation, for utilizing this for high-level operations such as thread-stack protection we need a common interface that is implemented for each BSP but is available for high-level operations ( Something along the lines of the cache manager ), my current implementation can be viewed here and here  My question is, what should be the correct placement of these APIs and hence there naming? Can we model it based on the cache-manager (rtems_memory_protection_xx_xx)?
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel