Skip to main content

Module multiplex

Module multiplex 

Source
Expand description

The self-multiplex spine (DESIGN §16.7 W12). yog’s own executable is the physical target of every embedded-tool spawn: a litany/bl/bz leading verb — yog litany <argv…>, yog bl <argv…>, yog bz <argv…> — dispatches here, to the arm that calls the embedded crate’s entrypoint exactly as each upstream’s own thin bin does (all three filled: W8/W10/W11), and so do balls’ two sibling plugin binaries — yog bl-delivery <op> <phase>, yog bl-tracker <op> <phase> (bl-2930, the U-balls-3 seam) — spawned by the embedded balls’ own plugin chain through the world/tools/ shims a yog bl prime binds. Everything else — no args, --editor-apply, yog env/yog exec, the GUI — is not a namespace and falls through (dispatch returns None).

How a wave fills an arm. Each namespace has one function, fn run(args: &[String]) -> i32. A wave lands by replacing exactly that one function’s body with the crate call — W8 filled [bl::run] (balls::run(&edge, args)), W10 filled [bz::run] ([crate::bz_host], brazen’s own main in this process), and W11 filled [litany::run] (litany’s own thin exec binding: parse cmd::Cli, run Command::preludes + Command::run, perform the Outcome including the successor exec). The routing, argv slicing, and exit plumbing here did not change — each wave also flipped its namespace’s Binary::self_multiplexed switch, so spawns target yog <namespace> and reach the filled arm. The two edits are the whole of a wave’s spine work.

A substrate arm stands its process in the world ([crate::world::inhabit], §16.2, bl-81c9): the bl and litany arms fold the override set into their own env, because the embedded crate reads getenv itself and spawns children that do too, so no Env value reaches either — one spelling, one world. The rest need no fold: bz’s state is per-wall, not per XDG (§16.2 as amended); the plugin arms are spawned by a balls that folded already; and gesture is yog’s own code over a composed Env. It is each arm’s own act, not the router’s, because the fold must land after that arm’s “touches nothing yet” point — for litany that is below the clap parse, which is what keeps a probe and a bad verb world-free.

main.rs (coverage-excluded) stays a thin call: dispatch(&argv) returns Some(code) (the process exits with it) or None (the GUI/hatch path, unchanged). All routing logic lives here, under test.

Modules§

landing
The landing repair the bl arm runs on the way in (§16.3, bl-7e54): a landing yog founded before balls’ config home was nested carries a schedule seeded from the operator’s stale template, and balls re-seeds a landing only when founding one. See the module doc.

Functions§

dispatch
Dispatch on the leading verb-namespace (argv[1]): Some(exit_code) when it names a namespace (the caller exits with it), None for anything else — no args, --editor-apply, env/exec, or the GUI, all unchanged (§16.7 W12). argv is the whole process argv; the namespace’s arm receives argv[2..].