On Thu, Mar 16, 2017 at 1:05 PM, Abhimanyu Rawat < h2015...@pilani.bits-pilani.ac.in> wrote:
> Hello Dr. Bloom, > > Sorry for writing after a big gap( was busy with a product integration), > although I found time to go through the pointers you put together for me, > thanks they were really helpful in getting an idea about the project and > how to process everything in time. > > Gaps are normal and acceptable (until you are getting paid for work :)). You should also expect to have gaps in responses from developers on the mailing list, since we are also generally volunteering. > I noticed that all the existing work on MMU is not moving very fast like > other supporting components for RTEMS, last year too no one was selected to > do MMU project #2904. I know only one guy applied but the proposal was not > quite promising. But trust me, all that doesn't make it any less desirable > for me to take it. Now, I have a few questions: > > I would not recommend judging the priority/value of a proposed project based on whether or not it was done in the past. Definitely discuss with mentors, etc. This project area is a good, long-term investment for RTEMS, but it does move slowly. > > On Fri, Mar 10, 2017 at 1:51 AM, Gedare Bloom <ged...@rtems.org> wrote: > >> >> >> On Thu, Mar 9, 2017 at 2:14 PM, Abhimanyu Rawat < >> h2015...@pilani.bits-pilani.ac.in> wrote: >> >>> Hello folks, >>> >>> I am Abhimanyu Rawat, a Computer Science Masters degree student from >>> BITS Pilani Campus, India. I found Memory Protection project #2904 >>> <https://devel.rtems.org/ticket/2904> very interesting and vital for >>> the the RTEMS. Among the lots of projects listed on the ideas page, Memory >>> Protection draws me to RTEMS as it's a very challenging project and I would >>> thoroughly enjoy working on it. I am a really enthusiastic person who would >>> like to contribute to the project. I have previous experience in C, C++ and >>> Python etc. At present I am an intern at EMC ^2 where I am working on >>> DataDomain Operating system, building configuration tool for the latest >>> DDOS software update. I have also lead a BITS-Stanford inter-university >>> project, where my team worked on Django based project with an inbuilt >>> authorization tool + chat application etc. I usually help my friends with >>> their projects as well. >>> >>> When does your internship complete, and when does your school year begin >> again? >> >> >>> As required, I went through the initial brief about the project and I >>> think it would be a valuable addition to RTEMS. Also, I have completed the >>> https://devel.rtems.org/wiki/GSoC/GettingStarted, and configured and >>> Built RTEMS for SPARC/erc32. Subsequently, I have the snapshot of the >>> terminal showing my name and the GSOC text as pictured here >>> <https://devel.rtems.org/attachment/wiki/GSoC/GettingStarted/SPARC-SIS-HelloWorld-Modded.png>. >>> Kindly tell me how selectively pointed towto send the proof of the >>> terminal and the diff file as required. >>> >>> Send to me by email is fine. >> >> >>> It would be great if you can give me some pointers about the structure >>> of the project and the direction I should pursue. >>> >>> Have a look at the current approach taken to provide low-level support >> for the MMUs in the ARM bsps. You can find this looking in the source tree >> via c/src/lib/libbsp/arm/* with most of the relevant parts in the shared >> subdirectory there, where each BSP defines a table of statically-configured >> MMU initialization. >> > > You selectively pointed towards the c/src/lib/libbsp/arm/* shared > subdirectory where some BSP's has low level code for MMU configuration, I > found ome cache code too. And trying digging deep to build a common > understanding of different BSP MMU code. The code initally is quite hard to > understand but as a unit what task is taking place is I can understand > like, data cache and line cleaing etc. Therefore I would request you to > provide me a documented code review or process guide( if available) so > that I can develop something to test the MMU code changes/patches, > otherwise I will have to brute force the search. As from this point I want > to move fast and reflect the my progress. > >> >> > I recommend that you start by writing a blog post about your understanding of what is implemented there. Look in the other BSPs to see what, if any, MMU code they have. Cache cleaning/invalidating is often tied with MMU state changes. > This is where the prior work has pretty much left off. Remaining items in >> this project area include: >> * Making a uniform approach to MMU/MPU setup across architectures >> > It seems nice to have a low level design which can point out the mutual > modules such as initialising the registers, stack and memory lines etc. For > this I think underying functionality have to be completed first or complete > the remaining pieces in existing code and then move bottom up. > > The underlying functionality exists for at least cp15-based ARM. Providing the functionality for another BSP family would be a good place to start. > * Supporting dynamic changes to MMU/MPU configurations >> * Leveraging dynamic MMU/MPU enforcement to create a mid-level memory >> management layers. Various proposals have been designed and implemented in >> the past that can be studied. >> > When you say dynamic changes, it means application level memory proection, > space quota management etc. ? I know you should be having a full list, so l > am willing to hear all that and then decide which work should be done first > and how I propose to do it. > > Dynamic here means the MMU entries can be changed at run-time after initialization. This is a building block for implementing higher-level services such as application-level memory protection and kernel-level APIs for memory management. > * Creating generally useful memory protection schemes such as per-task >> stack protection that can be enabled by applications with simple "switch it >> on" type of logic. >> > * Creating an application-layer interface for memory protection management >> at a finer granularity / with more application-level logic to control than >> the "generally useful" approaches would need. >> >> Ok this is exciting stuff that can be pushed first, the memory block or > segement(or whatever you say to a chunk but mostly I went through thesis > material online which denotes it as in different terms/name ) access > related control can be hacked together to provide the enclaved type of > execution for the application task. We can discuss more about it and how > much existing code base so far support this proposed project area. > > I prefer memory region to refer to a generic "Base+Offset" contiguous area of memory. We have discussed terminology quite often in the past. Reach out to Hesham to get some more details. We can't do application-level memory protection without a good understanding of the intermediate layers. We can start to design an API, but the API is not mergeable until there is a generic layer that is not tightly bound to the BSP or even CPU layers. > I look forward, to hear what is your take on them, and last but not the > least, thanks for the warm reply, it already makes me feel home with the > community. > > Overall, I look forward to working with the community and improving my >>> skills by actively contributing to the project(in long run also). >>> >>> *Closing with thank you and warm Regards,* >>> >>> *Abhimanyu Rawat* >>> *M.E. Computer Science, * >>> *CS/IS Department, BITS Pilani, Pilani Campus* >>> *Email - h2015...@pilani.bits-pilani.ac.in >>> <h2015...@pilani.bits-pilani.ac.in> / abhimanyura...@yahoo.com >>> <abhimanyura...@yahoo.com>* >>> *Phone. 08930399302 (call/Whatsapp), 09466899302* >>> >>> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ >>> ᐧ >>> >>> _______________________________________________ >>> 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