[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 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.

 >
 > This is confusing because each BSP is different and has different
 options. The tests should manage this internally at runtime and not be
 dependent on low level BSP specific driver implementations. We have polled
 console driver support in BSPs, why not get the tests to use it?
 >
 > Is this documented anywhere? FWIW I see adding some now as hiding the
 real issue.

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

 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.

 >
 > > > What do I do to make this happen?
 > >
 > > This is BSP-specific. Try, to add "ZYNQ_CONSOLE_USE_INTERRUPTS=" to
 the configure command line.
 >
 > <sigh> I will consider the blocker status for this issue and discuss it
 with Joel today. He told me yesterday no tests should be using `printk`
 unless configured to do so, ie small memory targets. There seems to be
 some confusion.

 Some tests must not use printf, due to execution environment constraints,
 e.g. interrupt context, no drivers, early system state, fatal error, etc.

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

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