Hello Utkarsh, I'd suggest you don't spend too much efforts on setting up BBB hardware if you haven't already. Debugging on QEMU with GDB is way easier, and you can consider either qemu-xilinx-zynq-a9 or rpi2 BSPs. Later, you can move your code to BBB if you want, since both are based on ARMv7.
On Thu, 7 May 2020 at 18:26, Utkarsh Rai <utkarsh.ra...@gmail.com> wrote: > > Hello, > This is to ensure that all the interested parties are on the same page before > I start my project and can give their invaluable feedback. > My GSoC project, providing user-configurable thread stack protection, > requires adding architecture-specific low-level support as well as high-level > API support. I will be starting my project with ARMv7-A (on BBB) based MMU > since RTEMS already has quite mature support for it. As already mentioned in > my proposal I will be focusing more on the High-level interface and let it > drive whatever further low-level support is needed. > Once the application uses MMU for thread stack address generation each thread > will be automatically protected as the page tables other than that of the > executing thread would be made dormant. When the user has to share thread > stacks they will have to obtain the stack attributes of the threads to be > shared by pthread_attr_getstack() and then get a file descriptor of the > memory to be mapped by a call to shm_open() and finally map this to the stack > of the other thread through > mmap(), this is the POSIX compliant way I could think of. Now at the low > level, it means mapping the page table of the thread to be shared into the > address space of the executing thread. This is an area where the low-level > support has to be provided. At the high-level, this means providing support > to mmap and shared-memory interface as mmap provides support for a file by > simply > copying the memory from the file to the destination. For shared memory > objects it can > provide read/write access but cannot provide restriction of write/read > access. One of the areas that I have to look into more detail is thread > context-switch, as after every context switch the TLBs need to be flushed and > reinitialized lest we get an invalid address for the executing thread. Since > context-switch is low-level architecture-specific, this also has to be > provided with more support. > Kindly provide your feedback if I have missed something or I have a wrong > idea about it. > > Regards, > Utkarsh Rai. > > _______________________________________________ > 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
