[RTEMS Project] #3170: Microzed libtest/block08 fails to print end of test correctly.

[RTEMS trac]

#3170: Microzed libtest/block08 fails to print end of test correctly.
------------------------------+--------------------------
 Reporter:  Chris Johns       |       Owner:  Chris Johns
     Type:  defect            |      Status:  assigned
 Priority:  high              |   Milestone:  4.12.0
Component:  unspecified       |     Version:  4.12
 Severity:  critical          |  Resolution:
 Keywords:  zedboard testing  |
------------------------------+--------------------------

Comment (by Chris Johns):

 Replying to [comment:10 Sebastian Huber]:
 > Replying to [comment:9 Chris Johns]:
 > > Replying to [comment:8 Sebastian Huber]:
 > > > Replying to [comment:7 Chris Johns]:
 > > > > I have always assumed the default configuration for '''any''' BSP
 lets the tests run. Is this not the case?
 > > > No, this is not the case for the real hardware BSPs which usually
 use an interrupt driven console driver.
 > >
 > > This seems like a new requirement. Has something changed in RTEMS to
 cause this? I do not remember having this problem with previous versions.
 >
 > At least since I use RTEMS, this was the case.  I asked questions about
 this on the mailing list.

 The beaglebone black does not have the same problems as the Zynq. I
 checked the drivers for the BBB and there is an interrupt version so I
 wonder if the polled driver is used by default. I did not check this.

 > The console drivers are a real mess. We have no link-time configuration
 options/mechanism for drivers. Its not so easy.

 If consoles provide interrupt and poll devs, why have the test close the
 console and reopen it with the polled driver? Yeah ok It is easy to say
 this and no I have not looked into the detail and what complexity there
 is. :)

 > Changing the tests so that they work with an interrupt driven console
 driver is hard.  I don't think it makes sense. What we need is a non-
 blocking test output support.

 Agreed, I was not considering changing the tests to do this rather how
 output is handled. There is the `TESTS_BUFFER_OUTPUT` and
 `TESTS_USE_PRINTK` can they be forced on and all `stdout` and `stderr`
 paths switched to what is used?

 > If you consider this as a blocker, then you possibly delay the release
 for several months.

 This is being a little dramatic. I am not after a rewrite, I am looking
 for a simple pragmatic solution. We need the ability to test on hardware
 in a repeatable manner for the life of the release branch.

--
Ticket URL: <http://devel.rtems.org/ticket/3170#comment:13>
RTEMS Project <http://www.rtems.org/>
RTEMS Project