GSoC: Correct placement and naming of memory protection APIs

[Gedare Bloom]

On Sat, Jul 18, 2020 at 3:55 AM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>
>
>
> 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).
>

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.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