cdtest and .gcc_exc section

[Charles.Gauthier at iit.nrc.ca (Charles Gauthier)]

IMHO, you can count on interrupt-driven I/O UNDER CERTAIN CONDITIONS
regardless of the BSP, assuming that the driver was implemented correctly.

1. Do not do I/O in static constructors/destructors.

2. Do not do I/O from tasks that run at a higher interrupt priority than
the I/O device.

Otherwise, everything should be ok.

Both problems do have solutions, but require discipline.

1. Call the appropriate __do_global_ctors() from the first
initialization task, and make sure that task runs with interrupts
enabled. This is trivial to do. The problem is running
__do_global_dtors(). Normally, this function is run at exit time. exit()
is a Posix process call that is, in my opinion, completely brain-damaged
in a multi-threaded system. It does not clean up every thread; only the
one that calls exit() and the global context. (If I am wrong on this,
please correct me).

So, don't ever call exit() in a real application. If you must shut down
in an orderly fashion, build it in into the application, and call
__do_global_dtors() explicitly.

2. If such tasks must do I/O, you should use a server. Buffer the I/O
requests and let a lower priority task do it while the higher priority
task is not running. It is your choice whether to implement blocking or
non-blocking semantics.

I don't understand what you mean by "console driver works outside the
RTEMS event handlers". The driver I wrote for the MVME167 supports
termios. It certainly works with RTEMS semaphores, but these semaphores
are part of the termios layer, not the driver itself. The driver gets
called by the termios layer, and calls back into that layer during
interrupt processing. Dirvers can make certain RTEMS OS calls, and can
use RTEMS objects. Look at the documentation.



Michael Collins wrote:
> 
> [Apologies for the truncated message sent earlier.  I got distracted and
> decided to bail, but hit ^D instead of ^C.]
> 
>   Anyway, my question is, can I count on interrupt-driven console I/O
> for normal applications.  Looking at the efi332 console driver, that
> would appear to be the case.  I also am under the impression that
> that console driver works outside the RTEMS event handlers, so it
> seems likely that properly implemented interrupts handlers will
> behave differently.
> 
>                                         -- MC --

-- 
Charles-Antoine Gauthier
Institute for Information Technology
National Research Council of Canada