Trying to review your proposal: 1) You've to allow comments/edit so that we can give feedback. 2) The proposal is not complete, you copied the template and didn't update all of the sections.
On Thu, Mar 30, 2017 at 8:27 AM, Abhimanyu Rawat < h2015...@pilani.bits-pilani.ac.in> wrote: > Hello Dr. Bloom and other folks, > > I have developed an initial draft of my application, kindly review it. I > can be more verbose in explaining the granular details regarding the > concepts and approaches, so kindly tell me how and where I can amend the > proposal. > > On Sat, Mar 25, 2017 at 12:15 PM, Hesham Almatary < > heshamelmat...@gmail.com> wrote: > >> >> >> On Sat, Mar 25, 2017 at 6:07 AM, Gedare Bloom <ged...@rtems.org> wrote: >> >>> Work on shaping your proposal document and start to plan the work you >>> would do during the summer. This is the best way for me to collaborate is >>> if you begin writing out your ideas in sufficient detail that I can >>> understand and provide feedback based on where you are at. >>> >> +1 >> >>> >>> On Fri, Mar 24, 2017 at 11:26 AM, Abhimanyu Rawat < >>> h2015...@pilani.bits-pilani.ac.in> wrote: >>> >>>> Hello Dr. Bloom, >>>> >>>> I have contacted to the past contributors, Peter and I will discuss >>>> PowerPC and further support, next week, in the meantime, I am going through >>>> PowerPC code and how I can build with the existing system a new bsp code >>>> for MMU/MPU support. I will complete my application next week. >>>> >>>> In the meantime, any suggestions from your side are most welcome. >>>> >>>> >>>> On Wed, Mar 22, 2017 at 8:57 PM, Gedare Bloom <ged...@rtems.org> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Mar 22, 2017 at 11:13 AM, Abhimanyu Rawat < >>>>> h2015...@pilani.bits-pilani.ac.in> wrote: >>>>> >>>>>> Indeed, PowerPC code is somewhat developed, would you recommend if >>>>>> there are some specific features in PowerPC that I should revisit? As >>>>>> this >>>>>> is little confusing as some work has been done on exception handler, page >>>>>> tables, cache already, so what should I target next and what to modify >>>>>> first? Past developer of the PowerPC support might help if you would >>>>>> connect me to? >>>>>> ᐧ >>>>>> >>>>>> I've CC'd some of the folks who previously worked on this topic. So >>>>> perhaps they have input for you. >>>>> >>>>> I think the important thing is that when we design a framework that it >>>>> is flexible enough to accommodate the many varieties of memory management >>>>> hardware. >>>>> >>>>> >>>>>> *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* >>>>>> >>>>>> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ >>>>>> >>>>>> On Wed, Mar 22, 2017 at 8:29 PM, Gedare Bloom <ged...@rtems.org> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Mar 22, 2017 at 10:07 AM, Abhimanyu Rawat < >>>>>>> h2015...@pilani.bits-pilani.ac.in> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Wed, Mar 22, 2017 at 7:17 PM, Gedare Bloom <ged...@rtems.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Please prefer to try to keep general GSoC / RTEMS project >>>>>>>>> discussions on the mailing list. Direct e-mail is ok but inefficient >>>>>>>>> in >>>>>>>>> many cases and should only be preferred for communciations of a >>>>>>>>> personal or >>>>>>>>> private matter. >>>>>>>>> >>>>>>>>> On Wed, Mar 22, 2017 at 5:33 AM, Abhimanyu Rawat < >>>>>>>>> h2015...@pilani.bits-pilani.ac.in> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Mar 17, 2017 at 9:25 PM, Gedare Bloom <ged...@rtems.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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/G >>>>>>>>>>>>>> SoC/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. >>>>>>>>>>> >>>>>>>>>>> Sure, setting up a medium blog to write about the bsp underlying >>>>>>>>>> code related to memory related operations. >>>>>>>>>> >>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> In case of arm-cp15 it's underlying fucntionality are far more >>>>>>>>>> developed(i.e. initialization, interrupt handling, underlying tlb >>>>>>>>>> update >>>>>>>>>> after fage faults etc.) than the rest of the bsp's, so I think we >>>>>>>>>> can start >>>>>>>>>> to design an API for application-level memory protection. This way >>>>>>>>>> we can >>>>>>>>>> have atleast one fully functional bsp for arm-cp 15, whose prototype >>>>>>>>>> can we >>>>>>>>>> can later use to speed up the development You think it can be a good >>>>>>>>>> proposal or shall I go with other bsp underlying support first? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> I'm concerned that any mid-level/high-level framework built on >>>>>>>>> top of the existing low-level support for arm-cp15 will be too rigid >>>>>>>>> to >>>>>>>>> work with less feature-ful BSPs/MMU/MPU combinations. It would be >>>>>>>>> good to >>>>>>>>> have another one or two kinds of MMU/MPU supported so that the upper >>>>>>>>> layers >>>>>>>>> can be more thoughtfully designed. >>>>>>>>> >>>>>>>>> >>>>>>>> I agree with your approach of having more than one type of bsp's >>>>>>>> with MMU/MPU support, so which one should I take on ? I mean I can >>>>>>>> work on >>>>>>>> AT91RM9200 of ARM family, or you would suggest other archiitecture >>>>>>>> like(PowerPC) ? >>>>>>>> >>>>>>>> PowerPC should be good. That was one of the targets worked on >>>>>>> previously, so it should not be too difficult. >>>>>>> >>>>>>> >>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> ᐧ >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> ᐧ >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> -- >> Hesham >> > > -- Hesham
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
