swung0x48
aba329cc53
Two things land together: the plan and contract draft P6 needs before it starts, and the
working notes that until now existed on exactly one machine.
1. P6's plan and contract draft (neither started; not one line of code)
docs/Disaggregated/P6-SPAWN-PLAN.md the package plan
docs/Disaggregated/P6-CONTRACT-DRAFT.md the contract draft (moves to
MG_Remote/CONTRACT-P6.md when c6 lands)
The three findings that mattered, all written into the documents:
a. P6 is SMALLER than its roadmap cell suggests. The transport primitives are already in
the tree and already tested: SocketDoorbell including hangup detection and the two
lost-wakeup fences (Doorbell.cpp:211-360, four cases in FdPassingTest), SCM_RIGHTS fd
passing, ShmSegment::Adopt, and the SurfaceOp / WindowKind schema already defined in
protocol.fbs. inproc uses a real second shm mapping rather than an alias, and
SessionRings.h:22-28 says that was done so today is not the first time it runs. P6 is
assembly plus a control plane plus a process, not "write a socket transport".
b. The evidence for "P6 is only a transport swap" has EXPIRED. It was bought by P5c, whose
audit found 59 direct memory accesses in a tree that already looked clean. P5e changed
the tree again. So the first package, a6, is a read-only audit that writes no code, and
every contract row that depends on it is marked PENDING a6 rather than decided in
advance.
c. P6 does not get a game running on the phone. ANativeWindow* is meaningless in the child,
and protocol.fbs:186-196's own comment says Android transfers the window out of band -
that band is P12. P6 lands pbuffer / surfaceless / offscreen, which is what HeadlessGL,
the split-equivalent lane and trace replay need, and which is exactly what P6's own exit
gate measures. A real window reaching the server is a named refusal. This gets its own
section because "P6 is done" would otherwise read as "the game runs now".
The contract adds rule G: a role may not name a process-local handle. It extends P5c's
rule E (a role may not name the other role's memory) from memory to identity - EGLDisplay /
EGLSurface / EGLContext / ANativeWindow* / fd number / pid / mapped address either cross as
a token this contract defines or they do not cross, and a descriptor crosses only through
SCM_RIGHTS, where the kernel renumbers it.
What P5e left for P6 gets its own section. The latch semantics are already designed
(ARCHITECTURE.md:504) and are copied unchanged. What is new is that after run-ahead the
client no longer waits while the peer process can DIE: the client holds records that were
published and will never be applied, and Android's freezer suspends the child without
closing anything. So slow and dead must be distinguishable WITHOUT a timeout threshold.
That is P6's only new design; everything else is carriage. It shares a predicate with E1's
outstanding re-specification (ID-122), and the two should be designed together.
Two gates carried over from P5e's lessons: G2 requires integration-spawn's test-name set to
match integration-split's name for name, because a differing set means the lane is quietly
running less; and the arm-proof gate requires every entry to record the child pid and
transport=spawn in its OWN private log - ID-124 established that this kind of false green
really happens, and a spawn lane that actually ran monolith would pass every other gate.
S2's shape must be settled before it is written, and the document says why: E1 is the
cautionary case.
2. The working notes move into the repository (docs/Disaggregated/notes/, 415 .md files)
ROADMAP / CURRENT_STAGE_PROGRESS / MEASUREMENTS cite ruling numbers, audit line numbers and
the provenance of gate figures from ~/w7/notes/, a directory that exists on one machine and
is under no version control. A record cited hundreds of times that lives only locally is not
a record, so it moves in whole, with its directory structure intact.
Only .md moves. Scripts, run logs, census and gate result JSON, patches, APKs and nm dumps
stay where they are: they are evidence DATA rather than documents - large, regenerated per
run, and mostly carrying absolute paths and device serials that mean something only on the
machine that produced them. The mapping and this split are written in
docs/Disaggregated/notes/README.md.
Two exceptions are recorded there too: P6's BRIEF has been promoted to a first-class
document and keeps no copy under notes/, so the two cannot drift apart; and recovered/ holds
material salvaged from failed workflow runs, which may duplicate the like-named phase
directories and is kept because a few of those were the only complete version at the time.
CI's citation lint takes docs/Disaggregated/*.md only (non-recursive), and notes/ is
deliberately outside it: those notes' file:line citations were written against their own
code heads, and resolving them against today's HEAD would fail wholesale - which is not an
error, it is their correct state as a historical record. To check one, use the revision it
declares (--rev).
3. Inconsistencies fixed in passing
- README.md's status line still said P5e was in progress while the stage table already said
closed.
- CURRENT_STAGE_PROGRESS's next-step item 1 still listed the exit gate as pending, though
(a) and (b) were run in the previous commit; rewritten to closed plus the one item that
actually remains (E1).
- ROADMAP's P6 row still had the pre-phase plan in three of its cells; it now carries the
package order, the scope boundary and the two new gates.
Checked with check_doc_citations.py: 125 citations across docs/Disaggregated/*.md, 0 problems.
7.1 KiB
Device verification brief (Kimi): build FCL with the P5e MobileGL and prove it still runs
You are verifying a rendering-library change on a real Android phone. The change under test is
MobileGL at commit 44f91c74 on branch feat/disaggregated: a large refactor (about 9,800 lines)
that stops the rendering backend from reading the GL frontend's live objects and makes it read the
pushed record stream instead. The threading is UNCHANGED by it — the split still runs lockstep —
so the question this run answers is "did the refactor break rendering?", not "is it faster". Build the launcher, install it,
run the game, and report what actually happened. Do not change any source file — if something does
not build or does not run, report it precisely; fixing it is not your job.
The one hard rule about hardware
The only device you may touch is the Redmi with serial 2f7cbe2e. Every adb command must carry
-s 2f7cbe2e. Never run a bare adb command that could pick another device, never adb disconnect/kill-server, never reboot, never factory-reset anything. The phone is rooted: adb -s 2f7cbe2e shell su -c '<cmd>' works when you need root (you need it only for the fan and the
thermal/clock reads below).
1. Build
Windows, Git Bash. The launcher repo is C:/Users/geekerwan/AndroidStudioProjects/FoldCraftLauncher;
its settings.gradle.kts already points the :MobileGL subproject at the worktree
MobileGL-disagg, which holds the change under test. Do not modify either.
cd /c/Users/geekerwan/AndroidStudioProjects/FoldCraftLauncher
export JAVA_HOME="C:/Program Files/Java/jdk-21"
export JAVA_TOOL_OPTIONS='-Djdk.net.unixdomain.tmpdir=C:\Users\geekerwan\.gradle\uds'
./gradlew.bat :FCL:assembleFordebug -Pmobilegl.buildDisaggregated=ON -Pmobilegl.buildDisaggregatedInproc=ON -Pmobilegl.pipePush=ON --console=plain
JAVA_TOOL_OPTIONSis not optional: without it every gradle invocation dies withUnable to establish loopback connection.- The three
-Pflags are what select the split (disaggregated) build of the native library. A build without them is not the thing under test. - Expect ~1-3 minutes and
BUILD SUCCESSFUL. If it fails withCould not move temporary workspace ... transforms, that is a known flaky gradle cache error — run the same command again once. Any other failure: capture the first 40 lines of the error (especially anyerror:line naming a.cpp/.hfile) and STOP; report it. - Output:
FCL/build/outputs/apk/fordebug/FCL-fordebug-1.3.3.2-all.apk(~717 MB). Record its timestamp and confirm it is newer than when you started.
2. Install
adb -s 2f7cbe2e install -r /c/Users/geekerwan/AndroidStudioProjects/FoldCraftLauncher/FCL/build/outputs/apk/fordebug/FCL-fordebug-1.3.3.2-all.apk
Expect Success. Confirm with
adb -s 2f7cbe2e shell "dumpsys package com.tungsten.fcl.mgdebug.debug | grep lastUpdateTime".
3. Prepare the run
# split (the thing under test):
adb -s 2f7cbe2e shell "echo inproc > /sdcard/FCL/mg_transport.txt"
adb -s 2f7cbe2e shell "rm -f /sdcard/FCL/mg_env.txt" # no extra env for the first run
# fan on so nothing thermal-throttles, and keep the screen awake:
adb -s 2f7cbe2e shell "su -c 'echo 2 > /sys/class/xm_power/hw_monitor/pwm_fan/target_level'"
adb -s 2f7cbe2e shell input keyevent KEYCODE_WAKEUP
adb -s 2f7cbe2e shell input keyevent 82
adb -s 2f7cbe2e shell svc power stayon true
adb -s 2f7cbe2e logcat -c
/sdcard/FCL/mg_transport.txt selects the transport at launch: inproc = the split build under
test, monolith = the single-threaded control.
4. Run and watch
Start a background log capture, then launch. The app counts down ~5 s and auto-launches Minecraft
26.3-rc-3 into the world test; the world takes 1-3 minutes to load.
adb -s 2f7cbe2e logcat -v time -s MobileGL:I > /c/.../kimi-run-inproc.log 2>&1 &
adb -s 2f7cbe2e shell am start -n com.tungsten.fcl.mgdebug.debug/com.tungsten.fcl.activity.SplashActivity
The in-world signal is the renderer's own periodic line in that log:
MGPipe stats: frames=<N> window=120 draws=<M> draws/f=<D> ...
The game is genuinely rendering the world once three consecutive lines show draws/f above ~400
(a menu draws a handful; the world draws ~850). frames= must keep climbing.
Once in-world, let it run 60 seconds, then collect:
- fps: from two
MGPipe stats:lines ~30 s apart —(frames2 - frames1) / (seconds between their timestamps). Report the number and the two lines you computed it from. - a screenshot:
adb -s 2f7cbe2e exec-out screencap -p > /c/.../kimi-inproc.png, then look at it and say in one sentence what is on screen (a Minecraft world? a black screen? a menu?). - liveness:
adb -s 2f7cbe2e shell pidof com.tungsten.fcl.mgdebug.debugmust still print a pid. - the failure scan: search the whole captured log for
Fatal{,FATAL,abort,SIGSEGV,SIGABRT,RoleViolation,UnmigratedPipeInput,UnmigratedVerb,ProtocolCorruption. Alsoadb -s 2f7cbe2e logcat -d -b crash -v time | tail -40. Quote verbatim anything you find — one of these lines is the single most important thing you can bring back. Note: two lines are EXPECTED and harmless, ignore them:Failed to load EGL function: eglSwapBuffersWithDamageEXTand... eglUnlockSurfaceKHR.
Then stop it: adb -s 2f7cbe2e shell am force-stop com.tungsten.fcl.mgdebug.debug.
5. The control run
Repeat section 3-4 with echo monolith > /sdcard/FCL/mg_transport.txt and a separate log file
(kimi-run-monolith.log, kimi-monolith.png). This is the same library running single-threaded: it
tells us whether anything you saw in the split run is specific to the change or true of both.
6. Restore the device
adb -s 2f7cbe2e shell am force-stop com.tungsten.fcl.mgdebug.debug
adb -s 2f7cbe2e shell "su -c 'echo 0 > /sys/class/xm_power/hw_monitor/pwm_fan/target_level'"
adb -s 2f7cbe2e shell svc power stayon false
adb -s 2f7cbe2e shell "echo monolith > /sdcard/FCL/mg_transport.txt"
7. The report
Write it to the path given at the end of this brief BEFORE your final message, then answer with two
lines: the report path and a one-word verdict (PASS / FAIL / BLOCKED).
The report must contain, in this order:
- Verdict, one line: does the split build run the game normally? PASS only if it reached the world, kept rendering for 60 s, showed no Fatal/crash, and the screenshot shows the world.
- Build: the command you ran, BUILD SUCCESSFUL or the error, the APK timestamp, whether you had to retry.
- Split run: time to in-world, the fps you computed and the two lines behind it, the screenshot description, pid alive yes/no, and the failure scan (verbatim quotes or "none found").
- Monolith run: the same four items.
- A short comparison: split fps vs monolith fps, and anything that differed between the two runs.
- Anything unexpected you saw and did not understand — describe it rather than explaining it away.
Do not edit source files, do not commit anything, do not push, do not touch any other device or any other repository. If a step cannot be completed, say which step and why, and continue with the steps that do not depend on it.