Examine the optional interfaces, which nothing did

⚠️⚠️ 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.

Author: speak-agent

.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: |

src/exec.cpp

@@ -43,6 +43,35 @@ int kal_exec_publish(void* p, kal_uintptr size) {
                                 static_cast<okl_long>(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;
 }