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