Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

shell/doc: Point users who run into shell buffer issues to the stdin buffer #20541

Merged
merged 1 commit into from
Apr 9, 2024
Merged

shell/doc: Point users who run into shell buffer issues to the stdin buffer #20541

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions sys/include/shell.h
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -75,6 +75,19 @@ extern "C" {

/**
* @brief Default shell buffer size (maximum line length shell can handle)
*
* @warning When terminals that buffer input and send the full command line in
* one go are used on stdin implementations with fast bursts of data,
* it may be necessary to increase the @ref STDIO_RX_BUFSIZE to make
* practical use of this buffer, especially because the current mechanism of
* passing stdin (`isrpipe_t stdin_isrpipe`) does not support backpressure
* and overflows silently. As a consequence, commands through such terminals
* appear to be truncated at @ref STDIO_RX_BUFSIZE bytes (defaulting to 64)
* unless the command is sent in parts (on many terminals, by presing Ctrl-D
* half way through the command).
*
* For example, this affects systems with direct USB stdio (@ref
* usbus_cdc_acm_stdio) with the default terminal `pyterm`.
*/
#define SHELL_DEFAULT_BUFSIZE (128)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this not the same as STDIO_RX_BUFSIZE?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't comment on the authors' intentions, but generally I do still think that these are different -- SHELL_DEFAULT_BUFSIZE is about the longest command, STDIO_RX_BUFSIZE is about how many bytes are tolerated to be sent w/o blocking on the application to process them into the buffer (and 64 is surprisingly large for that purpose). Their relation only matters in the case of a line-buffered terminal, which is a choice outside of the control of the embedded application.

If we want to change code and not just docs, I'd prefer we do it right (by allowing backpressure or doing zero-copy) rather than creating a cross-layer configuration dependency when we're already struggling to get our configs transparent.


Expand Down
Loading