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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
