On Sat, Jul 18, 2020 at 1:21 PM Hesham Almatary < hesham.almat...@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.ra...@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@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
