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 ([email protected])
Kubuntu 25.04 • amd64-plain • QEMU/VirtualBox • GRUB2 boot targets
_______________________________________________
l4-hackers mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
l4-hackers mailing list -- [email protected]
To unsubscribe send an email to [email protected]
