sys/stdio: add stdio_notify to emit callback on write

[basilfx]

Contribution description

For #22350 I need to be able to execute scheduled work on the same thread that runs and executes the REPL. With the stdio module proving an stdin_isrpipe, this is not possible, unless you run a second thread to read and rebuffer, then waking up the main thread with something like thread flags. This definitely costs more memory and flash than this proposed solution.

After some experimentation, I came up with stdio_notify. This provides a way to register a write callback, that can be used in an application for aforementioned reason.

I made three deliberate choices (which are not set in stone though):

• I did not implement this as part of isrpipe, which I could have done too. With sys/isrpipe: add convenience helpers to improve sys/stdio #22426 providing isrpipe_available, this would be feasible. However, if you have the option to choose for isrpipe to begin with, then there are probably other methods to solve the same issue. With the stdio module, you cannot. It keeps isrpipe lightweight.
• I only add support for a single callback, because stdin is typically read by a single consumer.
• I debated whether it should be called stdio_notify or stdin_notify, but given that stdio_available is not called stdio_stdin_available, I went with stdio_notify.

stdio backends now have to route incoming bytes via stdio_rx_write()/stdio_rx_write_one(). When stdio_notify is disabled, it inlines directly. Public access to stdin_isrpipe has been marked as deprecated, and writing to it directly will not invoke the callback (which is still backwards compatible when disable). I set it to 2027.01 for now.

Testing procedure

A test application has been provided in tests/sys/stdio_notify, which exactly shows one of its main intended uses.

Issues/PRs references

This PR builds for stdio_uart, but not for others due to #22424. #22426 was split off as another improvement.

Declaration of AI-Tools / LLMs usage:

AI-Tools / LLMs that were used are:

• Claude Opus 4.8 for documentation and test generation
• Claude Opus 4.8 code review

[riot-ci]

Murdock results

❌ FAILED

9d2b82e fixup! tests/sys/stdio_notify: add test application

Success	Failures	Total	Runtime
10516	0	11083	09m:42s

Artifacts

[basilfx]

The failing test is likely a consequence of what #22424 fixes.

[mguetschow]

Thanks, I think this is a very useful addition - I've run into similar problems before while using the RIOT shell module which also unconditionally blocks right now. May be a nice follow-up to enhance the shell module so that it does not necessarily block the main thread from doing anything else.

Regarding your three choices:

• I did not implement this as part of isrpipe, which I could have done too. With #22426 providing isrpipe_available, this would be feasible. However, if you have the option to choose for isrpipe to begin with, then there are probably other methods to solve the same issue. With the stdio module, you cannot. It keeps isrpipe lightweight.

Agree to your reasoning.

• I only add support for a single callback, because stdin is typically read by a single consumer.

True, and it wouldn't be very helpful for a second consumer to be woken up if stdin is drained by the time it is scheduled.

• I debated whether it should be called stdio_notify or stdin_notify, but given that stdio_available is not called stdio_stdin_available, I went with stdio_notify.

Also +1

I haven't tested it yet, so no formal approval yet - and we should definitely hold this back until after hard feature freeze anyhow.

[mguetschow]

That seems to have done the trick!

Time for and squash and a final test?

I guess you meant to post this at #22424?

[basilfx]

That seems to have done the trick!
Time for and squash and a final test?

I guess you meant to post this at #22424?

It was too late yesterday, and too early this morning ;-P