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.
> On Mar 16, 2016, at 15:27 , Joel Sherrill <j...@rtems.org> wrote: > > Hi > > I know this is a very old piece of code and predates printk() but should > this routine be changed to use printk()? > > Is it still safe? Especially in light of SMP demands. > > --joel > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering This email, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering. Contact HDA to discuss methods we can use that ensure secure communication.
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
