feat(openkal): the two consumers move to 0.9.0 with it - #276
Merged
Conversation
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.
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
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.
The two packages that consume openkal, moved to 0.9.0 with it.
riscv-virt-rtstd-freestanding-alloc-kalFollows #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:
count, because the bytes reached the device and a caller told
kal_err_iowould send them twice;
kal_memory_granularityanswers 1 — no memory management unit, norounding, so every address and every length is acceptable;
kal_versionandkal_interfacesare exported, and the latter claims exactlythose three.
linker took all fourteen names into the test binary, so
nmshowed them and thesuite was green — proving it compiles and links, and saying nothing about what it
answers.
tests/openkal.cppnow asks, on both ISA profiles, and was measured tofail when the answers are wrong.
std-freestanding-alloc-kal 0.1.2
kal_allocandkal_freeare 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.