From 9cb74188a0e8411d015a6851222aaa4325c81e62 Mon Sep 17 00:00:00 2001 From: speak-agent Date: Thu, 27 Aug 2026 21:31:39 +0800 Subject: [PATCH 1/2] Examine the optional interfaces, which nothing did MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ⚠️⚠️ THE STEP WAS NAMED "Every interface, every kind of examination" AND SELECTED THE HOSTED SET. `full' expands to `standard,abi,stability,cost' and `standard' is `core,env,time,fs,process,task'. The five interfaces openkal 0.8 added --- net, datagram, timeout, exec, space --- are in `optional', and this implementation provides all of them; without naming that set the suite compiled each of their sections with the body removed and reported them as not examined. Nothing failed. Nothing was checked either, and the sections had been written, merged and released in that state. Measured after the change, on this machine: 143 observations held, 0 did not hold, 1 not observed --- the one being openkal.terminal, which needs a standard stream that is interactive and has none in a pipeline. Also records why `kal_exec_publish' does NOT invalidate the instruction cache here while openkal-macos and openkal-windows do. The specification places that maintenance upon the program and the conformance suite performs it itself; on this implementation's three architectures `__builtin___clear_cache' becomes a CALL to `__riscv_flush_icache' on one of them, and acquiring a link-time dependency upon the compiler's support library --- in an implementation that sits beneath a C library, for an operation the specification does not require of it --- is a worse trade than the asymmetry. The comment is the change; the code is unaltered, so no version moves. --- .github/workflows/ci.yml | 15 ++++++++++++++- src/exec.cpp | 29 +++++++++++++++++++++++++++++ 2 files changed, 43 insertions(+), 1 deletion(-) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 6eae1d4..a8f82c0 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -172,7 +172,20 @@ jobs: - name: Every interface, every kind of examination run: | - bash .spec/tools/run-conformance.sh openkal-linux . full + # ⚠️⚠️ `optional` IS PART OF THE SET AND WAS NOT, WHICH MADE THE STEP'S + # OWN NAME UNTRUE. + # + # `full` expands to `standard,abi,stability,cost`, and `standard` is + # the HOSTED set — core, env, time, fs, process, task. The five + # interfaces openkal 0.8 added are in `optional`, and this + # implementation provides all of them; without naming that set the + # suite compiled their sections with the bodies removed and reported + # them as not examined. Nothing failed, and nothing was checked. + # + # This implementation is the one that may name `optional` entire: it + # is the only one providing every interface, which is why it is the + # reference. A backend that declines one names the others by hand. + bash .spec/tools/run-conformance.sh openkal-linux . full,optional - name: Point at the specification's working tree run: | diff --git a/src/exec.cpp b/src/exec.cpp index bef827d..ea0a764 100644 --- a/src/exec.cpp +++ b/src/exec.cpp @@ -43,6 +43,35 @@ int kal_exec_publish(void* p, kal_uintptr size) { static_cast(bytes), okl::prot_read | okl::prot_exec); if (okl::failed(r)) return okl::translate(r); + + // ⚠️⚠️ THE INSTRUCTION CACHE IS NOT INVALIDATED HERE, AND THE OTHER TWO + // IMPLEMENTATIONS DO INVALIDATE IT. THE ASYMMETRY IS DELIBERATE. + // + // A processor with separate caches for data and instructions has just had + // bytes written through the data path that it is about to fetch through the + // instruction path, and nothing in the protection call makes the second path + // observe the first's writes. + // + // ⭐ THE SPECIFICATION PLACES THE MAINTENANCE UPON THE PROGRAM, and the + // conformance suite performs it itself and says why: the program is the + // party that knows which bytes it wrote. So an implementation that performs + // it is being helpful rather than conforming, and one that does not is not + // deficient. + // + // ⚠️ AND HERE IT WOULD COST SOMETHING THE OTHER TWO DO NOT PAY. + // `__builtin___clear_cache' expands to nothing on x86_64 and to a + // maintenance sequence on aarch64 --- and on riscv64 it becomes a CALL to + // `__riscv_flush_icache', which lives in the compiler's support library. + // This implementation sits beneath a C library and is linked into programs + // that carry no other runtime; acquiring a link-time dependency upon that + // library, on one architecture, to perform an operation the specification + // does not require of it, is a worse trade than the asymmetry. + // + // openkal-macos reaches both of its architectures with the builtin alone + // and openkal-windows has a system call for it, so neither pays that price + // and both do it. The three agree about what the PROGRAM must do; they + // differ in whether the implementation does it as well, which no program + // that follows the specification can observe. return kal_ok; } From 1b00446ee7b58fe94ae4109c1264f0ffaebca699 Mon Sep 17 00:00:00 2001 From: speak-agent Date: Thu, 27 Aug 2026 21:45:52 +0800 Subject: [PATCH 2/2] State the instruction-cache rule the macOS measurement produced --- src/exec.cpp | 40 +++++++++++++++++++++++++--------------- 1 file changed, 25 insertions(+), 15 deletions(-) diff --git a/src/exec.cpp b/src/exec.cpp index ea0a764..5ebbb32 100644 --- a/src/exec.cpp +++ b/src/exec.cpp @@ -44,8 +44,8 @@ int kal_exec_publish(void* p, kal_uintptr size) { okl::prot_read | okl::prot_exec); if (okl::failed(r)) return okl::translate(r); - // ⚠️⚠️ THE INSTRUCTION CACHE IS NOT INVALIDATED HERE, AND THE OTHER TWO - // IMPLEMENTATIONS DO INVALIDATE IT. THE ASYMMETRY IS DELIBERATE. + // ⚠️⚠️ THE INSTRUCTION CACHE IS NOT INVALIDATED HERE, AND ONE OF THE THREE + // IMPLEMENTATIONS DOES INVALIDATE IT. THE ASYMMETRY HAS A RULE. // // A processor with separate caches for data and instructions has just had // bytes written through the data path that it is about to fetch through the @@ -58,20 +58,30 @@ int kal_exec_publish(void* p, kal_uintptr size) { // it is being helpful rather than conforming, and one that does not is not // deficient. // - // ⚠️ AND HERE IT WOULD COST SOMETHING THE OTHER TWO DO NOT PAY. - // `__builtin___clear_cache' expands to nothing on x86_64 and to a - // maintenance sequence on aarch64 --- and on riscv64 it becomes a CALL to - // `__riscv_flush_icache', which lives in the compiler's support library. - // This implementation sits beneath a C library and is linked into programs - // that carry no other runtime; acquiring a link-time dependency upon that - // library, on one architecture, to perform an operation the specification - // does not require of it, is a worse trade than the asymmetry. + // ⚠️ AND THE ONLY MEANS AVAILABLE HERE IS ONE THIS IMPLEMENTATION MAY NOT + // USE. `__builtin___clear_cache' expands to nothing on x86_64 and becomes a + // CALL into the compiler's support library on the other two architectures + // --- `__riscv_flush_icache' on riscv64. This implementation is linked into + // programs that carry no other runtime, so acquiring that dependency to + // perform an operation the specification does not require of it is not a + // trade worth making. // - // openkal-macos reaches both of its architectures with the builtin alone - // and openkal-windows has a system call for it, so neither pays that price - // and both do it. The three agree about what the PROGRAM must do; they - // differ in whether the implementation does it as well, which no program - // that follows the specification can observe. + // ⭐⭐ MEASURED, AND NOT ON THIS SYSTEM. openkal-macos added the builtin on + // the reading that aarch64 would expand it inline, and its own independence + // check reported within the hour: + // + // obj/exec.o references a symbol it must not: ___clear_cache + // + // ⇒ The three implementations share a rule rather than an accident: + // + // an implementation performs the maintenance where its environment + // offers it as a CALL of the environment's own --- openkal-windows has + // `FlushInstructionCache' --- and does not where the only means is a + // compiler builtin that becomes a dependency upon the compiler's + // support library. + // + // All three agree about what the PROGRAM must do, which is what the + // specification actually states. return kal_ok; }