Sorry, dropped my phone and the email was sent. > On 26 Jan 2017, at 3:24 pm, Sebastian Huber > <sebastian.hu...@embedded-brains.de> wrote: > > > > On 26/01/17 00:04, Chris Johns wrote: >>> On 25 Jan 2017, at 9:33 pm, Gedare Bloom <ged...@rtems.org> wrote: >>> >>> On Wed, Jan 25, 2017 at 2:07 AM, Sebastian Huber >>> <sebastian.hu...@embedded-brains.de> wrote: >>>> On 25/01/17 04:00, Gedare Bloom wrote: >>>>>>> On Tue, Jan 24, 2017 at 7:25 PM, Joel Sherrill<j...@rtems.org> wrote: >>>>>>> >>>>>>> >>>>>>> On Tue, Jan 24, 2017 at 6:23 PM, Gedare Bloom<ged...@rtems.org> wrote: >>>>>>> >>>>>>>>> Yes. They should fail with MAP_FAILED until we get a proper mmap(). >>>>>>>>> This can be either detected, or the test can be augmented until we get >>>>>>>>> mmap support for shm objects done. >>>>>>>>> >>>>>>> When you say augmented, you mean with an implementation of the >>>>>>> adapter layer you defined that uses malloc() and knows a few names? >>>>>>> >>>>> I mean to ignore/expect the MAP_FAILED return from mmap and terminate >>>>> gracefully. >>>>> >>>> In case MAP_FAILED is currently the expected return value on all >>>> architectures, then this should be expected by the test. When will there be >>>> a proper mmap() implementation exist? What is a proper mmap() >>>> implementation >>>> for RTEMS at all? >>>> >>> Timeline is not certain. I hope within 2 months. >>> >>>> I used mmap() on some GUI library to speed up the font initialization and >>>> simply mapped read-only font files (IMFS memfiles) via mmap(). It would be >>>> good to gather some use cases. I think Qt uses also mmap() for font files. >>>> >>> I know that mmap'ing files was a use case before. I have old code from >>> Chris to support it, and intend to extend/re-implement that support to >>> also provide mmap support for shm objects. >>> >> Why not tag the test as "excepted fail" in the .tcfg file for all archs? All >> testing frame works need to be updated to handle the new message at the >> start of the test and either report the excepted fail did fail or it passed, >> requiring we update the .tcfg file. > > The tests output should be self-describing. For this we need a new test > framework.
Did you try this and observe the output that indicates the expected fail state? The expect fail state should be printed in a manner external parsers can track it. The current test framework can handle this, and with a change to handle the "all" case as Joel observed is missing it should be enough to handle this case. I see another framework is a different topic. >> >> I prefer tests do not mask a failure when it exists and we should be or are >> in the process of fixing it. >> >> Chris > > The half finished test actually prevented a bug detection in the close > operation: > > https://git.rtems.org/rtems/commit/?id=090bdc7e9451467946463a2658adb9e777813f1c Improving tests is important. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
