On Tue, Jul 9, 2013 at 7:00 PM, Gedare Bloom <ged...@rtems.org> wrote:
> 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. > > A patch To include the stubs and high-level headers for every BSP and changes to all Makefile.am only ? > 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