On 2015-07-24 16:29, Philippe Gerum wrote: > On 07/23/2015 03:27 PM, Jan Kiszka wrote: >> On 2015-07-23 11:45, Philippe Gerum wrote: >>> On 07/23/2015 11:37 AM, Jan Kiszka wrote: >>>> On 2015-07-23 11:24, Philippe Gerum wrote: >>>>> >>>>> Hi Jan, >>>>> >>>>> Do you still have a use case for calling rt_print_auto_init(false) or >>>>> not calling rt_print_auto_init(true) from libcobalt's bootstrap code? >>>>> >>>> >>>> Huh, that was a day-one feature, now 8 years old, barely remember the >>>> details. I'm currently not aware of a concrete scenario. It definitely >>>> makes sense to revisit this think. >>>> >>>> I guess one, if not the major problem back then was that the implicit >>>> malloc of the initialization step was not consistently causing a >>>> SIGDEBUG warning. That is now different. >>>> >>> >>> Since the current thread won't be notified until XNWARN is armed in its >>> TCB, any objection to move that call as a nop placeholder to the compat >>> section in libtrank, leaving the implicit init to libcobalt as currently? >> >> Ack. >> > > Ok, let's see how deep you can dive into your context stack these days: > what about rt_print_cleanup() now? I see no in-tree callers, and I > wonder whether there is any use case for an application to stop the > stdio support during runtime.
I used to have one recently that was specifically interested in terminating the associated thread. But that case was modified later on due to other reasons. In principle, the value of this cleanup function is in the printer thread control, even if that means cutting of wrapped I/O (you could still print via unwrapped services then). Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux _______________________________________________ Xenomai mailing list [email protected] http://xenomai.org/mailman/listinfo/xenomai
