Summary

Currently, the SerialBuffer (1 MB ring buffer) is only used in PTY mode. In Socket mode, serial output is written directly to the raw UnixStream — when no client is connected, all output is silently dropped.

This makes Socket mode impractical for use cases where a client connects after boot (e.g., a cloud platform's serial console UI), since all prior output (kernel boot messages, cloud-init logs, etc.) is permanently lost.

Proposed Change

Wrap the UnixStream writer in SerialBuffer for Socket mode, the same way it's already done for PTY mode in serial_manager.rs:

// Current Socket mode (no buffering):
serial.lock().unwrap().set_out(Some(Box::new(writer)));

// Proposed (reuse SerialBuffer from PTY mode):
let write_out = Arc::new(AtomicBool::new(false));
let buffer = SerialBuffer::new(Box::new(writer), write_out.clone());
serial.lock().unwrap().set_out(Some(Box::new(buffer)));

This would give Socket mode the same 1 MB ring buffer behavior as PTY mode:

• When no client is connected → output accumulates in the buffer
• When a client connects → buffered output is flushed, then live streaming continues

Motivation

We're building a public IaaS platform using Cloud Hypervisor and need serial console access via a web UI. Socket mode is preferred over PTY for security reasons — the socket file is scoped to a pod's volume (isolated per VM), while PTY is created in the global /dev/pts/ namespace, accessible to any privileged process on the host.

However, without buffering, users who open the serial console after VM boot see a blank screen with no prior output. Adding SerialBuffer support to Socket mode would solve this with minimal code change, reusing existing infrastructure.