I found my solution yesterday! Thanks & I'll share. -- -- quark.cfg — Start cons and give StarForth its own NEW Vcon (stdin+stdout) -- local L4 =rawget(_G, "L4") or require("L4") local l =L4.default_loader -- 1) cons session factory local cons_mux =l:new_channel() -- 2) start cons (frontend is parent's serial; auto-connect "starforth") l :start({ caps = { cons = cons_mux:svr(), -- publish cons factory fe = L4.Env.log, -- cons frontend (serial/stdio) }, }, "rom/cons -m l4re -f fe -a -c starforth") -- If your cons expects 'log' instead of 'fe', use this instead : -- l :start({ -- caps ={ cons = cons_mux:svr(), log = L4.Env.log }, -- }, "rom/cons -m l4re -f log -a -c starforth") -- 3) tell loader to obtain log objects from cons (not the write-only logger) l.log_fab =cons_mux -- 4) start StarForth; loader asks cons to CREATE a NEW Vcon named 'starforth' l :start({ log = { "starforth", "yellow", "key=1", "show" }, }, "rom/starforth") On 9/3/25 15:03, Robert A. James wrote:

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:

o

works with |make qemu …| and |make grub2iso …|

o

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

_______________________________________________ l4-hackers mailing list --l4-hackers@os.inf.tu-dresden.de To unsubscribe send an email tol4-hackers-leave@os.inf.tu-dresden.de