Thanks for the feedback, I will proceed by keeping MPU implementation in mind for my proposal.
On Sun, Mar 15, 2020 at 5:21 AM Gedare Bloom <ged...@rtems.org> wrote: > On Sat, Mar 14, 2020 at 4:07 PM <dufa...@hda.com> wrote: > > > > > > > > > On Mar 14, 2020, at 14:22 , Gedare Bloom <ged...@rtems.org> wrote: > > > > > > Hi Utkarsh, > > > > > > On Sat, Mar 14, 2020 at 12:05 PM Utkarsh Rai <utkarsh.ra...@gmail.com> > wrote: > > >> > > >> I am in the middle of drafting the proposal for the memory protection > project and specifying the interface, one of the things I would like to > take to your feedback on is what are the functionalities that would be > provided to the users, as some of the architectures provide a lot of > support that others don't, should we keep that to a minimum or go with the > maximum options. For example, ARM provides 4kb, 16kb, and 64kb page > granules whereas others don't so either the users can be provided with the > option of accessing other stacks in granules of various sizes or a > common-minimum of 4kb. > > >> > > >> Also, it would be very kind of you if you could help me with the > previous message on this thread. > > >> > > >> On Wed, Mar 11, 2020 at 8:34 AM Utkarsh Rai <utkarsh.ra...@gmail.com> > wrote: > > >>> > > >>> Before specifying the interface I want to take your kind feedback on > what all things would need to be done in the interface. > > >>> > > >>> By looking into the MMU description of ARM and x86, according to me, > the implementation would have to be done in two levels- > > >>> > > >>> 1. The architecture-specific part, wherein I will have to initialize > the MMU(already implemented for ARM), TLB management and exception handling. > > > > > > Yes. This is done simply in a few ports where needed, usually just to > > > setup a 1:1 VA-PA mapping. > > > > > >>> 2. The generalization part, wherein I will need to manage the thread > stacks, their access permissions. Each stack should have a data structure > associated with it that has the permission flags, starting address and > other relevant information. For increased robustness of the thread stacks, > every time a context switch takes place we will have to set up the page > tables, TLBs to map the address of the executing thread as well as that of > the threads it has the permission to access. > > >>> > > > > > > I think Peter's advice is sound. We have a rough version of mmap > > > implemented. It has a few problems and isn't completely functional for > > > all use cases. The main question to consider as we move forward is > > > whether to allow n:1 VA-PA mappings, which implies a non-linear > > > address space. I think you will need to do some research about that > > > topic. I don't think it is a great idea though, since AFAIK it > > > requires an MMU to implement such mappings so if there is just an MPU > > > then things may break (or work in weird ways). > > > > > > > > > > The decision about memory protection unit versus memory management unit > is essential to decide how this should proceed. I believe we should > require only an MPU, a lot of the discussion would require an MMU. > > > > I agree. The basic features of the API should work with just an MPU, > say with 4 regions? That seems like a good "minimum requirement" to > design toward. HW with more regions or MMU (remapping, TLB) may > provide other optional features. > > This means that the 1:1 VA-PA mapping should continue to be > implied/understood in the design, and can be assumed in general. > > > Peter > > ----------------- > > Peter Dufault > > HD Associates, Inc. Software and System Engineering > > > > This email is delivered through the public internet using protocols > subject to interception and tampering. > > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
