Should rtems_error() use fprintf()?

[Chris Johns]

On 17/03/2016 06:41, Peter Dufault wrote:
> I’m answering only by looking at this email and not hunting through the
> source.  But if “rtems_error()” can easily be replaced by either
> "fprintf(stderr, …)" or "printk()" then deprecate it with that
> recommendation.  I’ve often had spirited discussions with clients
> because I think "fprintf(stderr, …)" needs to be supported cleanly in an
> embedded environment (as early as possible, and in as many environments
> as possible, leaving an escape hatch for a “printk()” in an ISR etc),
> since if the customer can’t use “fprintf(stderr, …)" they can’t use
> libraries easily.  The customer usually specifies a special
> “my_error_prinft(...)" that they want to use instead of “fprintf(stderr,
> …)”, and if that’s what “rtems_error()” is then deprecate it.

I think support for stderr is important. I have seen stderr used 
successfully by redirecting it (using cpukit/libmisc/redirector) to 
syslog collecting errors from a number of nodes in a system and also 
into a buffer for a web based log.

I have also seen it be over used so I encourage an application trace 
level or trace flags.

Chris