Tracking issue for output synchronisation between mbed_trace, printf...

[ithinuel]

Description of defect

Target(s) affected by this defect ?

Toolchain(s) (name and version) displaying this defect ?

What version of Mbed-os are you using (tag or sha) ?

mbed-os-99.99.99

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

N/A

How is this defect reproduced ?

Have multiple threads using the stdout put using Greentea, printf, mbed_trace.

This is a tracking issue to discuss to possible solution(s) to the output synchronization problem.

Mbed-os currently provides several mutually unaware ways to output traces and log messages to either a specific output and/or a retargetable destination.

This creates friction during development :

• corrupted greentea kv token generates false negative during CI testing.
• decreased readability of log renders difficult the debugging multithreaded tests.
• lowers the quality of the developer experience.

Prior discussion on #9954.

[ithinuel]

For the background history, I faced this issue when trying to build a Network Interface driver for a wifi module.
The driver dispatches its events in its own thread and prints logs using mbed_trace. However, greentea uses direct RawSerial, unity putc and some (most) of the netsocket tests are using printf.
Trying to reconstruct the corrupted log of intermingled messages coming from various parts of the software was a hassle, hence the hack proposed in #9954.

[0Grit]

What is the IDEAL design and feature-set for the various serial debug, test, logging, command line interfaces?

How do we hack what exists to get on the path to that ideal?

[ciarmcom]

Thank you for raising this issue. Please note we have updated our policies and
now only defects should be raised directly in GitHub. Going forward questions and
enhancements will be considered in our forums, https://forums.mbed.com/ . If this
issue is still relevant please re-raise it there.
This GitHub issue will now be closed.

[40Grit]

@adbridge Can this be considered a defect so that the discussion #11861 can be addressed?

Or should it be considered a new feature and PR created to discuss and implement?

[adbridge]

@40Grit we can make an exception in this case I think.