0.6.0 — adopt openkal 0.9, and ask this machine what its page is - #14
Merged
Conversation
⚠️ ⚠️ THE ALLOCATOR ASSUMED A FOUR-KILOBYTE PAGE ON A SYSTEM WITH TWO. `kPage' was the constant 4096, and this system's own hardware pages are four kilobytes on one architecture and SIXTEEN on the other. Allocation appeared to work, because a mapping rounded to four kilobytes is rounded up again by the kernel --- while `kal_free' unmapped a range SHORTER than the one mapped, and the remainder was never returned. The page is now asked for once, through `hw.pagesize', and `kal_memory_granularity' reports it. The rest follows the specification: * `kal_fs_props' takes the directory and consults the format the volume is, which this kernel names in words. A word per implementation could state none of its positions honestly here: the volume this system is ordinarily installed on compares names without regard to case and a volume attached to the same machine may not, and both are reachable through the preopen this implementation supplies; * asking now resolves a link, because opening always did; * transfers return one signed word; the parameters and names are copied into the caller's buffer and the length reported is the value's own; * `kal_node_info' carries its own size, reports what was filled, and carries the device and inode as an opaque identity; * `kal_fs_link_create' and `kal_fs_link_read' over symlinkat and readlinkat; * `kal_fs_max_name'; typed stream handles; `kal_version' and `kal_interfaces'. Ninety-five names are exported and none other, checked against SURFACE.txt.
Every README here opens by showing what a program writes in its manifest, which is the first thing a reader copies and the last thing anyone edits. These lines had drifted --- the specification's own README asked for a version four minor releases old --- and nothing checked them. `openkal/tools/check-readme-versions.sh` now does.
src/exec.cpp carried both answers. One comment reasoned that the write-then-publish order is the case an entitlement is not needed for and concluded the interface is provided unconditionally; another, thirty lines below, reasoned that executable memory is granted only to an artifact produced with one and returned zero from kal_exec_props. The operations behaved as the first said and the capability word said the second. The disagreement was invisible while every consumer was statically linked -- such a consumer never asks, it links the operations and uses them. It became load-bearing when an implementation's own account of itself became part of the ABI, and the conformance suite then reported what had been true all along: "an implementation that does not claim availability reserves nothing" did not hold, because this one claimed nothing and reserved anyway. Neither comment is the party that knows. Whether this system grants executable memory depends on how the artifact was signed, which is settled after this code is compiled. So the enquiry performs the thing it is asked about -- one reservation, one publish, one release -- and reports what the kernel said; kal_exec_alloc declines when it reports no. The two can no longer disagree. kPage = 4096 is also gone. The argument for it held for the reservation and failed for the release: munmap with a length shorter than the mapping unmaps less than was mapped, which is the defect src/memory.cpp records having measured on this same system one file away.
Measured 2026-08-28 across the eight repositories of this ecosystem while one change spanned all of them: eight jobs in four of them called `mcpp build' at a point where the manifest still named openkal BY VERSION, so a version under review -- which by definition is not published -- failed them with E_NOT_FOUND. The mechanism is not a missing substitution. run-conformance.sh substitutes the manifest and RESTORES IT ON EXIT, correctly; every step after it is back to naming a version. So an audit asking "does this job substitute?" passes the job and misses the steps, which is how the first pass at this found three repositories and not four. These steps are green on main and can only be green there, because there the published version is the one under test. It is not a check that fails, it is a check that cannot run at the only time it would have something to say. The substitution is also portable now: the opensbi and uefi portability jobs run on macOS and Windows, where BSD sed requires an argument to -i that GNU sed refuses.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
kPagewas the constant 4096, and this system's own hardware pages are fourkilobytes on one architecture and sixteen on the other. Allocation appeared to
work, because a mapping rounded to four kilobytes is rounded up again by the
kernel — while
kal_freeunmapped a range shorter than the one mapped, andthe remainder was never returned. The page is now asked for once, through
hw.pagesize, andkal_memory_granularityreports it.openkal 0.9
kal_fs_propstakes the directory and consults the format the volume is, whichthis kernel names in words. A word per implementation could state none of its
positions honestly here: the volume this system is ordinarily installed on
compares names without regard to case and a volume attached to the same machine
may not, and both are reachable through the preopen this implementation supplies.
caller's buffer and the length reported is the value's own.
kal_node_infocarries its own size, reports what was filled, and carries thedevice and inode as an opaque identity — which is what stops two different files
reading as one.
kal_fs_link_create/kal_fs_link_readoversymlinkat/readlinkat;kal_fs_max_name; typed stream handles;kal_versionandkal_interfaces.Ninety-five names exported and none other, checked against
SURFACE.txt.