Sir, I have studied about SASOS. It's really a great approach to make the process faster by avoiding multiple copies of the data. I read about two SASOS namely Angel system(developed at City University, London) and Mungi system(developed by University of New South Wales, Australia). I also studied about Memory Protection in SASOS, where the concept of address protection is replaced by protection domain. I studied about Multithreading, POSIX, Race condition and Synchronization to avoid the Race condition. Please guide me, am I on the right path and what all do I need to learn further?
Thanks and Regards Abhinav Jain On Wed, Jan 31, 2018 at 11:17 PM, Abhinav Jain <jainab.2...@gmail.com> wrote: > Sir, > > Thanks for the guidance. The mail is very informative and I will follow > the way suggested by you. > > Thanks and regards > Abhinav Jain > > On Jan 31, 2018 5:41 PM, "Sebastian Huber" <sebastian.huber@embedded- > brains.de> wrote: > >> The MMU support is a very challenging project. The scope of the project >> and potential use cases must be determined. You need a lot of experience to >> design good APIs and it helps if you know the APIs for this kind of stuff >> on other systems like QNX, Linux, FreeBSD, etc. For the architecture >> support a lot of background knowledge is required at least on PowerPC, >> ARMv5..8, SPARC, Nios2, MIPS, etc. For example, changing the TLB1 based MMU >> during application run-time on PowerPC (including SMP support, cache >> consistency) is not easy. There are some optimization problems involved if >> you want to determine a good cover with memory areas (alignment >> restrictions, limited number of areas in the MMU/MPU if not page based, >> e.g. 16). >> >> -- >> Sebastian Huber, embedded brains GmbH >> >> Address : Dornierstr. 4, D-82178 Puchheim, Germany >> <https://maps.google.com/?q=Dornierstr.+4,+D-82178+Puchheim,+Germany&entry=gmail&source=g> >> Phone : +49 89 189 47 41-16 >> Fax : +49 89 189 47 41-09 >> E-Mail : sebastian.hu...@embedded-brains.de >> PGP : Public key available on request. >> >> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >> >>
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
