You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* 0.3.0 --- adopt openkal 0.9
Transfers return one signed word. The parameters a program receives are copied
into the caller's buffer and the length reported is the value's own --- here
there are none, so each reports the condition, which is what distinguishes "no
such thing" from "one, and it is empty".
`kal_memory_granularity' is answered with a constant, which is what the
specification says the cheap answer should be, and `kal_version' and
`kal_interfaces' likewise. The second is worth having on this row in
particular: a machine with no storage, no second image and no scheduler has
those interfaces absent as definitions, and the word now says so rather than
leaving a consumer to discover it by failing to link.
* README: the versions it names are the versions that exist
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.
* ci: build against the specification under review, not the published one
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.
The README also asked a reader for openkal 0.5.1 against a specification now at
0.9.0, and examples/hello asked for 0.8.0. Both are lines a reader copies.
* ci: substitute the specification per step, not per job
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.
---------
Co-authored-by: speak-agent <x.d2learn.org@gmail.com>
0 commit comments