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/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. >>>> >>>> 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 >>>>>>> >>>>>> >>>>>> >>>>> ᐧ >>>>> >>>> >>>> >>> >> > ᐧ >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel