Conversation
The QEMU nographic console connects the host terminal to the guest /dev/hvc0 but forwards only the byte stream, never the terminal capability name. The kernel initializes PID 1 with TERM=linux, matching Linux 6.6.139 semantics, and BusyBox 1.35.0 init rewrites that value to vt102 once VT_OPENQRY on hvc0 reports that the console is not a Linux virtual terminal. That fallback is correct for a non-VT console, but it leaves terminfo-aware programs such as CodeBuddy and tput with a "no color" capability even though the host terminal renders 256 colors. Both launchers created the same console without passing TERM on the kernel command line: the Make/Bash entry point (tools/run-qemu.sh) and the Nix entry points (tools/qemu/default.nix). Fixing only one of them would produce entry-point dependent behavior, so the decision logic now lives in a single sourced helper instead of being duplicated. Add tools/qemu/console-term.sh, which resolves the console TERM for the x86_64 BusyBox/hvc0 session: - Automatic mode only applies to QEMU nographic stdio with both stdin and stdout attached to a TTY, where QEMU transparently forwards bytes and the host TERM describes the actual rendering endpoint. The host value is propagated verbatim; an unset TERM, dumb or linux leaves the guest fallback untouched. - DRAGONOS_QEMU_CONSOLE_TERM takes priority when set, covering Unix socket clients, automation and manually selected terminfo entries. Because BusyBox cannot preserve it on hvc0, an explicit value of linux is rejected with an error rather than silently degraded. - Regardless of source, the candidate must be a 1-32 byte ASCII string matching [A-Za-z0-9][A-Za-z0-9._+-]* under LC_ALL=C. The value ends up in a space separated kernel command line, so whitespace, '=' and control characters cannot inject extra kernel parameters. - When nothing resolves, no TERM keyword is emitted and the existing x86_64 BusyBox vt102 fallback is preserved. Wire the helper into both entry points and log the resolved value and its source. The change is limited to x86_64 nographic; RISC-V and LoongArch use different init paths and are left unchanged. No kernel, TTY or application behavior is modified, and no capability is overstated: the host TERM is propagated exactly, so a missing guest terminfo entry remains a rootfs data concern rather than being masked by an incorrect mapping. Signed-off-by: longjin <longjin@dragonos.org>
Member
Author
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. You're on a roll. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The QEMU nographic console connects the host terminal to the guest
/dev/hvc0but forwards only the byte stream, never the terminal capability name. The kernel initializes PID 1 withTERM=linux(matching Linux 6.6.139 semantics), and BusyBox 1.35.0 init rewrites that tovt102onceVT_OPENQRYonhvc0reports that the console is not a Linux virtual terminal — correct behavior for a non-VT console. The result is that terminfo-aware programs such as CodeBuddy andtputobserve a "no color" capability even though the host terminal renders 256 colors.Neither entry point passed
TERMon the kernel command line:tools/run-qemu.shstart-*/yolo-*tools/qemu/default.nixFixing only one of them would produce entry-point dependent behavior, so the decision logic lives in a single sourced helper instead of being duplicated.
Changes
Add
tools/qemu/console-term.sh, which resolves the consoleTERMfor the x86_64 BusyBox/hvc0 session:TERMdescribes the actual rendering endpoint and is propagated verbatim. An unsetTERM,dumborlinuxinjects nothing, preserving the guest fallback.DRAGONOS_QEMU_CONSOLE_TERMtakes priority, covering Unix socket clients, automation and manually selected terminfo entries. Because BusyBox cannot preserve that value onhvc0, an explicitlinuxis rejected with an error rather than silently degraded.[A-Za-z0-9][A-Za-z0-9._+-]*underLC_ALL=C. The value ends up in a space separated kernel command line, so whitespace,=and control characters cannot inject extra kernel parameters.TERMkeyword is emitted and the existing x86_64 BusyBoxvt102fallback is preserved.Both entry points wire in the helper and log the resolved value and its source.
Scope and invariants
VT_OPENQRYis not faked into succeeding, and 256 colors are not hardcoded in/etc/profile,/opt/env.shor any application.COLORTERM. The hostTERMis propagated exactly, so a missing guest terminfo entry remains a rootfs data concern rather than being masked by an incorrect mapping.Verification
In an interactive x86_64 nographic session with host
TERM=xterm-256color, the boot log reportsGuest console TERM=xterm-256color (source=host),tput colorsreturns256after login, and CodeBuddy emits 256-color SGR sequences. With a non-TTY stdio or an unsetTERM, noTERMkeyword is emitted and behavior matches the pre-change baseline.Testing
DRAGONOS_QEMU_CONSOLE_TERMexplicit override and rejection of invalid valuesTERMkeeps the fallback