Skip to content

feat(openkal): the two consumers move to 0.9.0 with it - #276

Merged
Sunrisepeak merged 1 commit into
mainfrom
release/openkal-consumers
Aug 29, 2026
Merged

feat(openkal): the two consumers move to 0.9.0 with it#276
Sunrisepeak merged 1 commit into
mainfrom
release/openkal-consumers

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

The two packages that consume openkal, moved to 0.9.0 with it.

package version was what changed
riscv-virt-rt 0.6.0 0.5.2 its openkal implementation adopts the 0.9 surface, and is now exercised
std-freestanding-alloc-kal 0.1.2 0.1.1 a repin; nothing on the allocation path changed

Follows #275, which added
openkal 0.9.0 and the eight packages that implement or stand on it.

riscv-virt-rt 0.6.0

It supplies openkal's core set — abort, stream, memory — behind
features = ["openkal"], so it is an implementation and not only a consumer.
Three things follow from 0.9:

  • transfers are one signed word; a partial write that then fails reports the
    count, because the bytes reached the device and a caller told kal_err_io
    would send them twice;
  • kal_memory_granularity answers 1 — no memory management unit, no
    rounding, so every address and every length is acceptable;
  • kal_version and kal_interfaces are exported, and the latter claims exactly
    those three.

⚠️ Nothing called any of it before. The feature compiled the sources and the
linker took all fourteen names into the test binary, so nm showed them and the
suite was green — proving it compiles and links, and saying nothing about what it
answers. tests/openkal.cpp now asks, on both ISA profiles, and was measured to
fail when the answers are wrong.

std-freestanding-alloc-kal 0.1.2

kal_alloc and kal_free are unchanged in 0.9.0, so the package is a repin.
Writing it exposed that its manifest dependency catches a version mismatch
and not a declaration one — it declares the two itself rather than including
openkal's header. Continuous integration now compiles both against the header
they came from.

What was checked

Both source tarballs were downloaded from both hosts and compared byte for
byte against the file the checksum was taken from. Both descriptors parse as Lua
afterwards and carry the version in all three OS tables with the same checksum,
checked on the parsed table rather than by searching the text.

riscv-virt-rt 0.6.0 and std-freestanding-alloc-kal 0.1.2, following #275.

riscv-virt-rt is not only a consumer: behind `features = ["openkal"]` it
supplies openkal's core set for QEMU's RISC-V virt machine, so 0.9's one-word
transfers, kal_memory_granularity and the self-description all had to be
implemented. Its granularity answers 1 -- no memory management unit, no
rounding -- and its comment records that a C library above it must impose its
own floor rather than adopt the number.

⚠️ Nothing had ever called that implementation. The feature compiled the sources
and the linker took all fourteen names into the test binary, so the suite was
green while proving only that it compiles and links. It now has a test that asks,
on both ISA profiles, measured to fail when the answers are made wrong.

std-freestanding-alloc-kal is a repin: kal_alloc and kal_free are unchanged and
nothing 0.9 altered is reachable from `operator new`. Writing it exposed that its
manifest dependency catches a version mismatch and not a declaration one -- it
declares the two itself rather than including openkal's header -- so continuous
integration now compiles both against the header they came from.

Both tarballs were downloaded from both hosts and compared byte for byte against
the file the checksum was taken from. Both descriptors parse as Lua afterwards
and carry the version in all three OS tables with the same checksum, checked on
the parsed table rather than by searching the text.
@Sunrisepeak
Sunrisepeak merged commit 7c3afc4 into main Aug 29, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant