0.4.0 — adopt openkal 0.9, and report the coarser of this system's two granularities - #15
Merged
Merged
Conversation
…two granularities ⭐⭐ THIS SYSTEM HAS TWO MEMORY QUANTA AND IS THE REASON THE SPECIFICATION ASKS FOR ONE NUMBER RATHER THAN A PAGE SIZE. It protects memory in pages of four kilobytes and RESERVES it in units of sixty-four, so a value taken from either alone is wrong for the other. What `kal_memory_granularity' promises is that an address and a length that are multiples of it are acceptable to every operation of the interface, and the coarser of the two is the only answer that keeps that promise. A specification that had derived the number from the page size of one family of systems would have been wrong here. `kal_fs_props' takes the directory and asks this environment what the volume can do, which it reports itself --- so nothing is guessed: case sensitivity is read rather than assumed absent, and a volume that holds nodes whose content is another name is reported as holding them.⚠️ Those nodes are REPORTED and are not MADE, and the enquiry says so before a caller tries. Creating one here requires a privilege an ordinary program does not hold or the system's developer mode, and reading one requires a control code this implementation does not yet issue. Neither is claimed, and both operations refuse rather than being absent, because a caller can ask first --- which is what makes the refusal admissible rather than the defect clause 6.2 names. The rest follows the specification: transfers return one signed word; the parameters and names are copied into the caller's buffer; `kal_node_info' carries its own size, what was filled, and an identity taken from the volume's serial number and the file's index --- two words because this environment's index is unique WITHIN a volume and one word would make two files on two volumes read as one; asking resolves a node unless told not to; typed stream handles; `kal_version' and `kal_interfaces'. Ninety-three names are exported and none other: the two `openkal.space' names are absent, which is what the word reports as well.
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.
A job that resolves the published specification cannot review a change to one.
Another job in this file already cloned the specification and substituted it,
and that made the arrangement look complete. It was not: the steps below reached
openkal by version, so a version under review -- which by definition is not
published -- failed them with
E_NOT_FOUND: package 'compat.openkal@0.9.0' not found in the synced index
... the index is current, so this name is either wrong or not published yet
The unit is the job, not the repository. Measured across the eight repositories
of this ecosystem while one change spanned all of them: seven jobs in three of
them had this shape, and each of those repositories also had a job doing it
correctly -- which is what made the gap invisible to a check done a repository
at a time.
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.
Also: GetSystemInfo is declared in src/win32.h and was exported by no .def, so
the completeness check named it. It belongs to kernel32.
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.
FILE_FS_VOLUME_INFORMATION ends in the volume's label, which is as long as the label is. The buffer here held the fixed part and one character of it -- enough for every field this reads, since the serial number precedes the label -- and the object manager still reported STATUS_BUFFER_OVERFLOW because the label did not fit. That value is 0x80000005: negative, so okw::ok said no, so the identity position was left clear. Which is a correct report of something that was not true. This implementation was saying "this node's identity is not known here", a caller was believing it, and the identity was sitting in the buffer. It surfaced two packages away, in openkal-musl's probe on Windows: "two different files have different identities" did not hold, because both had been given the zero this branch leaves behind. The conformance suite could not have said so and is right not to -- an implementation is allowed to decline the field, so the suite reports the observation as one it did not make. Room for a label is given so the ordinary case succeeds, and the overflow is accepted so the extraordinary one still answers.
…wo of each
The check's own comment records the defect it was written to prevent: three
declarations added for openkal 0.8 without matching .def lines, and the failure
appearing one repository away in openkal-llvm-runtime's cross-build. It happened
again, with the same signature:
ld.lld: error: undefined symbol:
__declspec(dllimport) NtQueryVolumeInformationFile
The check was right and its SCOPE was wrong, which is the harder kind to notice:
it read src/win32.h alone and matched `OKW_IMPORT ... OKW_API' alone, while
src/win.h declares the object manager's entries in the plain
`__declspec(dllimport) long __stdcall Nt...' form. It reported a number, the
number was of the names it knew about, and nothing said the set was partial.
It now globs src/*.h and matches both forms: 58 declared across four headers
rather than 49 across one. Four names were outside it -- NtFlushBuffersFile,
NtQueryVolumeInformationFile, NtReadFile, NtWriteFile -- and all four are now
exported. Only one of them was referenced, which is why only one broke a link;
the other three were the same latent hazard.
Verified locally by cross-building openkal-llvm-runtime's same-source example
for x86_64-windows-gnu and aarch64-macos over these working trees.
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.
⭐⭐ This system has two memory quanta and is the reason the specification asks for one number rather than a page size
It protects memory in pages of four kilobytes and reserves it in units of
sixty-four, so a value taken from either alone is wrong for the other. What
kal_memory_granularitypromises is that an address and a length that aremultiples of it are acceptable to every operation of the interface, and the
coarser of the two is the only answer that keeps that promise. A specification
that had derived the number from the page size of one family of systems would
have been wrong here.
openkal 0.9
kal_fs_propstakes the directory and asks this environment what the volume cando, which it reports itself — so nothing is guessed: case sensitivity is read
rather than assumed absent, and a volume that holds nodes whose content is
another name is reported as holding them.
caller tries. Creating one here requires a privilege an ordinary program does
not hold or the system's developer mode, and reading one requires a control code
this implementation does not yet issue. Neither is claimed, and both operations
refuse rather than being absent — because a caller can ask first, which is what
makes the refusal admissible rather than the defect clause 6.2 names.
Also: transfers return one signed word; values are copied into the caller's
buffer;
kal_node_infocarries its own size, what was filled, and an identitytaken from the volume's serial number and the file's index — two words because
this environment's index is unique within a volume and one word would make two
files on two volumes read as one; asking resolves a node unless told not to.
Ninety-three names exported and none other: the two
openkal.spacenames areabsent, which is what
kal_interfacesreports as well.