On Sat, Jul 18, 2020 at 3:55 AM Utkarsh Rai <utkarsh.ra...@gmail.com> wrote: > > > > 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). >
The score is the "least common denominator" for functional implementation in RTEMS. Any code that is shared by more than one API must generally belong in the score. I can't seem to find where this is described in our documentation. Although it's really outdated now, you can get a sense of things from Section 2 of https://gedare.github.io/pdf/bloom_scheduling_2014.pdf Since you have something that needs to be accessible from POSIX with some implementation in architecture/BSP-specific code, the only place that could be implemented is in the score. >> >> >> >> 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
