GSoC: Correct placement and naming of memory protection APIs
utkarsh.rai60 at gmail.com
Sat Jul 18 09:55:35 UTC 2020
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.
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...
More information about the devel