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) ? 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
