Hello l4-hackers,

My name is Robert (Bob) A. James I'm VERY new to the L4Re world. This is also my first foray into systems programming having come from the Medical Device and Enterprise areas during my career. I am now retired and developing a full Operating System based on L4Re/Fiasco.OC.

I’m looking for guidance on the canonical way to wire an interactive text console (stdin/stdout) for a user program under L4Re/Fiasco.OC on amd64-plain.

Context

• I have a small, headless FORTH VM (“StarForth”) running under L4Re/Fiasco.OC; its self-tests pass. What’s missing is an interactive REPL.

• Target outcomes:
  a) Run via make qemu E=starforth O=build-x86_64
  b) Build GRUB2 ISO via make grub2iso E=starforth O=build-x86_64
  c) ISO runs in QEMU and VirtualBox
  d) Same ISO boots on commodity x86_64 hardware

What I’ve tried (and where I’m stuck)

1. Vcon + cons (almost there)

   • My mental model: Vcon as a frontend; cons providing the console service; StarForth as the “backend” client/subscriber.

   • Behavior I see:
     • The “terminal” prints what the logger prints rather than the process’s normal stdout.
     • Output sometimes flushes only on newline; interactive prompts without \n don’t appear reliably.

   • Aside from those two issues, this was close to a working REPL.

   • Questions: Is cons effectively write-only (log)? If so, what’s the supported input-capable console frontend to bind both stdin and stdout for a user process? Is there a minimal example showing correct capability wiring so user stdout/stderr don’t get mixed with the system log?

2. GOOS/Framebuffer route

   • I attempted a tiny terminal server that maps the GOOS framebuffer and renders an 8×16 CP437 font. I did not get this path working end-to-end, so I’m fine dropping it if there’s a simpler, recommended console approach.

What would help

• The recommended minimal pattern (modules/services + boot script) to give a user task a real interactive stdin/stdout:

  • works with make qemu … and make grub2iso …

  • also works on typical PCs without a full graphics stack.

• A small reference that: (1) prints text, and (2) reads keystrokes from the user, with a snippet of modules.list and the Lua loader snippet.

Environment / details

• L4Re/Fiasco.OC on amd64-plain, built with the L4Re toolchain.

• Intended entry points: make qemu E=starforth O=build-x86_64, make grub2iso E=starforth O=build-x86_64.

One of my simple boot variants (for reference):

modules.list (simplified)

entry starforth
kernel fiasco -serial_esc
roottask moe rom/quark.cfg
module l4re
module ned
module cons
module quark.cfg
module starforth
quark.cfg --> I think this is about what I had.

-- rom/quark.cfg
local L4 = require("L4")
local ld = L4.default_loader

-- Start cons; feed it to the real serial logger (fe = L4.Env.log)
local cons_ctl = ld:new_channel()
ld:start({
   caps = {
   cons = cons_ctl:svr(),  -- server gate for cons' factory
   fe   = L4.Env.log,      -- cons frontend goes to serial/log
   },
}, "rom/cons -m l4re -f fe -a -t -c StarForth")  -- ← added -c StarForth

-- Ask cons to create a Vcon client for StarForth and pass it in as 'tty'
-- (Capabilities are first-class in Ned; calling 'create' on caps is supported.)
local tty = cons_ctl:create(L4.Proto.Log, "StarForth", "show", "key=1", "bufsz=65536")

-- Start StarForth with that Vcon as its TTY
ld:start({
   caps = {
   tty = tty,  -- the Vcon client for StarForth
   },
}, "rom/starforth")
I can share a minimal reproducible case (sources, build logs, QEMU output) off-list if that helps.

Thanks in advance for any pointers to the “right way,” or to a maintained example I can follow.

Best regards,
R. A. “Bob” James (rajames440@gmail.com)

Kubuntu 25.04 • amd64-plain • QEMU/VirtualBox • GRUB2 boot targets