When we do the initial commit of libmm, we should link every BSP/CPU to the nop stub implementation. We can probably get started on merging that baseline soon. Hesham, if you can pull out a patch containing just the nop implementation we can review it.
On Tue, Jul 9, 2013 at 12:53 PM, Hesham Moustafa <heshamelmat...@gmail.com> wrote: > > > > On Tue, Jul 9, 2013 at 6:47 PM, Rempel, Cynthia > <cynt6...@vandals.uidaho.edu> wrote: >> >> >>Is there a way to conditionally build the mmtests based on whether libmm >> >> is being built? >> >>My initial thought is something like an AM_CONDITIONAL >> >> >> >>http://www.gnu.org/software/automake/manual/html_node/Subdirectories-with-AM_005fCONDITIONAL.html >> >>Although another way to conditionally build the tests may be better... >> >> >> >>Ideally if we went that route (and if feasible), if there was a >> >> conditional being used for building libmm, we would use the same >> >> conditional >> >> for the libmm tests... >> >Sure, I can work on that. >> Thanks! >> My main concern is if a BSP doesn't have libmm built, will building all >> the tests lead to a compiler / linker error? >> If not, we needn't worry about building conditionally... > > There are stubs for libmm functions at a high-level APIs at > no_memorymanagement.c file. So, every BSP/CPU that does not implement libmm > functions can be built without error with including that file. >> >> >> >> >> >> I'm mostly worried about getting these tests committed incrementally if >> feasible (i.e. they don't break the build)... >> >> Hopefully we can get your work committed over the summer and reduce the >> number of patches at the end of the summer :) >> >> --- >> >> I noticed there wasn't a copyright on the .doc s. Could you add >> >> # COPYRIGHT (c) 2013. >> # Hesham Moustafa. >> # >> # The license and distribution terms for this file may be >> # found in the file LICENSE in this distribution or at >> # http://www.rtems.com/license/LICENSE. >> >> To the top of >> mmtest1/mmtest1.doc >> mmtest2/mmtest2.doc >> mmtest3/mmtest3.doc >> >> Thanks! >> Cindy >> ________________________________________ >> From: rtems-devel-boun...@rtems.org<mailto:rtems-devel-boun...@rtems.org> >> [rtems-devel-boun...@rtems.org<mailto:rtems-devel-boun...@rtems.org>] on >> behalf of Rempel, Cynthia >> [cynt6...@vandals.uidaho.edu<mailto:cynt6...@vandals.uidaho.edu>] >> Sent: Monday, July 08, 2013 3:55 PM >> To: Hesham Moustafa; rtems-devel@rtems.org<mailto:rtems-devel@rtems.org> >> Cc: Gedare Bloom >> Subject: RE: [GSoC] libmm project status >> >> Hi, >> >> Thanks for providing the link directly to the testcases! >> Could you copy the information about each test into: >> >> mmtest1/mmtest1.doc >> Simple tests that tries to install memory management entries >> >> mmtest2/mmtest2.doc >> + Install entries with specific memory attributes (e.g read only region) : >> + Check for memory protection violations (writing to read only blocks) >> + Reading from read only blocks. >> + Write/Read to/from unmapped region (error!). >> + Write to a valid entry that was installed and then uninstalled (error!). >> >> mmtest3/mmtest3.doc >> + Tests for libmm behavior on SMP environments. >> + Create tasks for each core and start it. >> + Check for memory consistency and page tables and memory attributes >> validity. >> >> That way we can quickly identify what each test does in 5 years... Good >> job with the documentation :) >> >> Cindy >> ________________________________________ >> From: rtems-devel-boun...@rtems.org<mailto:rtems-devel-boun...@rtems.org> >> [rtems-devel-boun...@rtems.org<mailto:rtems-devel-boun...@rtems.org>] on >> behalf of Hesham Moustafa >> [heshamelmat...@gmail.com<mailto:heshamelmat...@gmail.com>] >> Sent: Monday, July 08, 2013 3:39 PM >> To: rtems-devel@rtems.org<mailto:rtems-devel@rtems.org> >> Cc: Gedare Bloom >> Subject: [GSoC] libmm project status >> >> Hi all, >> >> I have posted a new thread to my blog that contains a brief introduction >> to libmm and latest updates, here is the thread [1] Please take a look. >> >> TODO: port libmm for Raspberry PI board on real hardware. >> >> Questions : >> >> I have created a new test case at libtests called mmtest3 [2] which >> simulate SMP use case on QEMU/Realview. It simply tries to invoke the same >> task (which calls libmm function) for each core. There is a fatal error at >> startup that branches to data exception handler but I am not sure why. >> Please take a look and tell me if I am doing something wrong with that test >> case. >> >> Other test cases (mmtest1, mmtest2) run successfully on the same platform. >> >> [1] >> http://heshamelmatary.blogspot.com/2013/07/gsoc-2013-libmm-for-rtems.html >> [2] >> https://github.com/heshamelmatary/rtems-gsoc2013/tree/low-level-libmm/testsuites/libtests/mmtest3 >> >> Regards, >> Hesham >> >> >> _______________________________________________ >> rtems-devel mailing list >> rtems-devel@rtems.org<mailto:rtems-devel@rtems.org> >> http://www.rtems.org/mailman/listinfo/rtems-devel >> >> >> >> > > > _______________________________________________ > rtems-devel mailing list > rtems-devel@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel > _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
