GSoC: Correct placement and naming of memory protection APIs

[Utkarsh Rai]

On Sat, Jul 18, 2020 at 1:21 PM Hesham Almatary <
hesham.almatary at cl.cam.ac.uk> wrote:

> 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


While designing my interface I went through this and my model is almost
similar to yours :). My doubt is, what are the rationales for placing this
in the score? (If you look into my commit history, I have fiddled with the
placement quite a bit without any resolution).


>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200718/f2ef3896/attachment.html>