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