Should rtems_error() use fprintf()?
chrisj at rtems.org
Wed Mar 16 23:57:14 UTC 2016
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.
More information about the devel