Uh oh!
There was an error while loading. Please reload this page.
Make litebox_shim_linux generic over its platform - #1056
Merged
Jay Bosamiya (Microsoft) (jaybosamiya-ms) merged 3 commits intoJul 21, 2026
Conversation
…iplex The Linux shim was hard-wired to the global `litebox_platform_multiplex::Platform` singleton (set via `set_platform`, fetched via `platform()`). This made the shim non-generic and forced platform selection through cargo features. Parameterize the shim over a platform type `Platform` end-to-end (alongside the existing `FS`): `LinuxShimBuilder<Platform>`, `LinuxShim<Platform, FS>`, `GlobalState`, `Task`, `LoadedProgram`, and every subsystem type (epoll, unix sockets, eventfd, channels, signals, process/thread state, transport, ELF loader). `LinuxShimBuilder::new(platform)` now takes a `&'static Platform`; the global accessor is gone. - Add a sealed `ShimPlatform` aggregate bound (with blanket impl) so impls read `impl<Platform: ShimPlatform, FS: ShimFS>`. It also pins the associated types the shim relies on: ThreadProvider::ExecutionContext = PtRegs, Timer/Signal Provider::Signal = common Signal, and VmemPageFaultHandler. - Remove the litebox_platform_multiplex dependency and platform_* features from litebox_shim_linux. Tests pick a concrete platform by build target via a `TestPlatform` alias (LinuxUserland / WindowsUserland) with target-scoped dev-deps. - Update the runners to depend on their concrete platform crate and instantiate `LinuxShimBuilder::new(platform_ref)`: linux_userland (LinuxUserland), linux_on_windows_userland (WindowsUserland), snp (SnpLinuxKernel). The SNP page-fault handler reaches the platform through a new `LinuxShim::platform()` accessor instead of a global. - Update README to describe the threaded-platform model.
John Starks (jstarks)
marked this pull request as ready for review
July 21, 2026 08:26
Jay Bosamiya (Microsoft) (jaybosamiya-ms)
approved these changes
Jul 21, 2026
Jay Bosamiya (Microsoft) (jaybosamiya-ms)
left a comment
Member
There was a problem hiding this comment.
Overall LGTM, I've made a few minor notes of nits, I've also updated the PR description to reduce some of the verbosity.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Member
Also, since semver-checks CI bot does not fire on branches from forks, here's its output as of 04dc576 (basically expected tweaks): click to unfold |
Uh oh!
There was an error while loading. Please reload this page.
pullBot
pushed a commit
to Mu-L/litebox
that referenced
this pull request
Jul 22, 2026
Makes SNP shim initialization safer via `OnceBox`, and cleans up some documentation.
Sangho Lee (sangho2) pushed a commit
that referenced
this pull request
Jul 28, 2026
…#1056 `set_platform` was a private one-liner with a single caller, wrapping one `OnceRef::set`. It mirrored the shape of `litebox_platform_multiplex`, which needed a setter because it was a separate crate exporting one to foreign callers. Inside a single module with one call site it is ceremony, and it made the design read as more global-oriented than it is. `init` now sets the cell directly and `platform()` is the sole named accessor. The `PLATFORM` cell itself stays and cannot reasonably go: `Platform::new` runs only on the BSP and leaks its result, and the AP bring-up trampoline is naked assembly whose only payload is the `is_bsp` flag in `edi`, so an AP has no channel to receive the pointer. The doc comment now states that rather than gesturing at it. Two artifacts found by comparing against how PR #1056 handled the same job for litebox_shim_linux: - The shim's test helper still branched on `cfg(not(target_os = "linux"))` to call a different `Platform::new`. `Platform` is now hardcoded to `LinuxUserland`, so that arm was unreachable and would not have compiled. - The CI `no_std` allow-list rationale for `litebox_shim_optee` claimed it "depends on `litebox_platform_multiplex`", which is no longer true. #1056 deleted the equivalent entry for litebox_shim_linux outright. That is not possible here: building litebox_shim_optee for `x86_64-unknown-none` still fails, but in `sha2`, for the same soft-float/asm reason `litebox_service_heki` is excluded. The entry stays; the comment now says why.
Sangho Lee (sangho2) pushed a commit
that referenced
this pull request
Jul 28, 2026
`litebox_shim_optee` was hard-wired to `litebox_platform_multiplex::Platform`, so the platform was chosen by cargo feature and fetched from a panicking global. `litebox_platform_lvbs` separately reached itself through `platform_low()`. This parameterizes the shim over its platform, mirroring what #1056 did for `litebox_shim_linux`, and gives LVBS one sanctioned platform accessor. Neither was reachable without first fixing `GlobalVmapManager`. Its `manager()` is a `self`-less method returning `&'static Self::Manager`, so every implementor had to reach a global -- which is the reason both `platform_low()` and `multiplex::platform()` were on the physical-pointer paths. The trait is gone; `PhysMutPtr`/`PhysConstPtr` now hold `mgr: &'m M` and take it at construction. Every construction site outside `litebox_common_linux` is a short-lived local, so the lifetime never escapes a function body. `litebox_shim_optee` is generic over `Platform`, bounded by `OpteeShimPlatform`. The bound includes `VmapManager<PAGE_SIZE>`, so the shim's need to touch normal-world physical memory is stated in the type system rather than implied by the selected platform. The session registry moves to each runner: a `static` cannot name a generic parameter and a shim is built per session, so the shim has nowhere to hold it, while a runner names a concrete platform. `litebox_platform_lvbs` keeps a single instance behind `platform()`, renamed from `platform_low()` and documented as intended rather than as a workaround. A `static` is required regardless -- APs receive only `is_bsp` from the bring-up trampoline -- so the choice was only whether the one instance has one home or many. Caching it in the types that need it was tried and abandoned: it put seven handles to the platform inside the platform's own structs. The three VSM gates and `PrivilegedVmap` stay zero-sized. Both runners name their platform directly. Neither gains anything it lacked: `litebox_runner_optee_on_linux_userland` already depended on `litebox_platform_linux_userland` with `optee_syscall`, which is what the multiplex feature enabled. `litebox_platform_multiplex` then has no consumers and is deleted, along with its workspace entries, ratchet entry, and `no_std` CI allow-list entry. Globals ratchet: litebox_platform_lvbs 23 (unchanged), litebox_runner_lvbs 6 -> 7 for the session registry, a new entry of 1 for litebox_runner_optee_on_linux_userland, and litebox_platform_multiplex removed. Also corrects two stale CI artifacts: the `no_std` rationale for `litebox_shim_optee` claimed a multiplex dependency, when it is excluded because its crypto dependencies fail to build for `x86_64-unknown-none`, as with `litebox_service_heki`.
Sangho Lee (sangho2) pushed a commit
that referenced
this pull request
Jul 28, 2026
`litebox_shim_optee` was hard-wired to `litebox_platform_multiplex::Platform`, so the platform was chosen by cargo feature and fetched from a panicking global. `litebox_platform_lvbs` separately reached itself through `platform_low()`. This parameterizes the shim over its platform, mirroring what #1056 did for `litebox_shim_linux`, and gives LVBS one sanctioned platform accessor. Neither was reachable without first fixing `GlobalVmapManager`. Its `manager()` is a `self`-less method returning `&'static Self::Manager`, so every implementor had to reach a global -- which is the reason both `platform_low()` and `multiplex::platform()` were on the physical-pointer paths. The trait is gone; `PhysMutPtr`/`PhysConstPtr` now hold `mgr: &'m M` and take it at construction. Every construction site outside `litebox_common_linux` is a short-lived local, so the lifetime never escapes a function body. `litebox_shim_optee` is generic over `Platform`, bounded by `OpteeShimPlatform`. The bound includes `VmapManager<PAGE_SIZE>`, so the shim's need to touch normal-world physical memory is stated in the type system rather than implied by the selected platform. The session registry moves to each runner: a `static` cannot name a generic parameter and a shim is built per session, so the shim has nowhere to hold it, while a runner names a concrete platform. `litebox_platform_lvbs` keeps a single instance behind `platform()`, renamed from `platform_low()` and documented as intended rather than as a workaround. A `static` is required regardless -- APs receive only `is_bsp` from the bring-up trampoline -- so the choice was only whether the one instance has one home or many. Caching it in the types that need it was tried and abandoned: it put seven handles to the platform inside the platform's own structs. The three VSM gates and `PrivilegedVmap` stay zero-sized. Both runners name their platform directly. Neither gains anything it lacked: `litebox_runner_optee_on_linux_userland` already depended on `litebox_platform_linux_userland` with `optee_syscall`, which is what the multiplex feature enabled. `litebox_platform_multiplex` then has no consumers and is deleted, along with its workspace entries, ratchet entry, and `no_std` CI allow-list entry. Globals ratchet: litebox_platform_lvbs 23 (unchanged), litebox_runner_lvbs 6 -> 7 for the session registry, a new entry of 1 for litebox_runner_optee_on_linux_userland, and litebox_platform_multiplex removed.
Sangho Lee (sangho2) pushed a commit
that referenced
this pull request
Jul 29, 2026
`litebox_shim_optee` was hard-wired to `litebox_platform_multiplex::Platform`, so the platform was chosen by cargo feature and fetched from a panicking global. `litebox_platform_lvbs` separately reached itself through `platform_low()`. This parameterizes the shim over its platform, mirroring what #1056 did for `litebox_shim_linux`, and gives LVBS one sanctioned platform accessor. Neither was reachable without first fixing `GlobalVmapManager`. Its `manager()` is a `self`-less method returning `&'static Self::Manager`, so every implementor had to reach a global -- which is the reason both `platform_low()` and `multiplex::platform()` were on the physical-pointer paths. The trait is gone; `PhysMutPtr`/`PhysConstPtr` now hold `mgr: &'m M` and take it at construction. Every construction site outside `litebox_common_linux` is a short-lived local, so the lifetime never escapes a function body. `litebox_shim_optee` is generic over `Platform`, bounded by `OpteeShimPlatform`. The bound includes `VmapManager<PAGE_SIZE>`, so the shim's need to touch normal-world physical memory is stated in the type system rather than implied by the selected platform. The session registry moves to each runner: a `static` cannot name a generic parameter and a shim is built per session, so the shim has nowhere to hold it, while a runner names a concrete platform. `litebox_platform_lvbs` keeps a single instance behind `platform()`, renamed from `platform_low()` and documented as intended rather than as a workaround. A `static` is required regardless -- APs receive only `is_bsp` from the bring-up trampoline -- so the choice was only whether the one instance has one home or many. Caching it in the types that need it was tried and abandoned: it put seven handles to the platform inside the platform's own structs. The three VSM gates and `PrivilegedVmap` stay zero-sized. Both runners name their platform directly. Neither gains anything it lacked: `litebox_runner_optee_on_linux_userland` already depended on `litebox_platform_linux_userland` with `optee_syscall`, which is what the multiplex feature enabled. `litebox_platform_multiplex` then has no consumers and is deleted, along with its workspace entries, ratchet entry, and `no_std` CI allow-list entry. Globals ratchet: litebox_platform_lvbs 23 (unchanged), litebox_runner_lvbs 6 -> 7 for the session registry, a new entry of 1 for litebox_runner_optee_on_linux_userland, and litebox_platform_multiplex removed.
Sangho Lee (sangho2) pushed a commit
that referenced
this pull request
Jul 29, 2026
`litebox_shim_optee` was hard-wired to `litebox_platform_multiplex::Platform`, so the platform was chosen by cargo feature and fetched from a panicking global. `litebox_platform_lvbs` separately reached itself through `platform_low()`. This parameterizes the shim over its platform, mirroring what #1056 did for `litebox_shim_linux`, and gives LVBS one sanctioned platform accessor. Neither was reachable without first fixing `GlobalVmapManager`. Its `manager()` is a `self`-less method returning `&'static Self::Manager`, so every implementor had to reach a global -- which is the reason both `platform_low()` and `multiplex::platform()` were on the physical-pointer paths. The trait is gone; `PhysMutPtr`/`PhysConstPtr` now hold `mgr: &'m M` and take it at construction. Every construction site outside `litebox_common_linux` is a short-lived local, so the lifetime never escapes a function body. `litebox_shim_optee` is generic over `Platform`, bounded by `OpteeShimPlatform`. The bound includes `VmapManager<PAGE_SIZE>`, so the shim's need to touch normal-world physical memory is stated in the type system rather than implied by the selected platform. The session registry moves to each runner: a `static` cannot name a generic parameter and a shim is built per session, so the shim has nowhere to hold it, while a runner names a concrete platform. `litebox_platform_lvbs` keeps a single instance behind `platform()`, renamed from `platform_low()` and documented as intended rather than as a workaround. A `static` is required regardless -- APs receive only `is_bsp` from the bring-up trampoline -- so the choice was only whether the one instance has one home or many. Caching it in the types that need it was tried and abandoned: it put seven handles to the platform inside the platform's own structs. The three VSM gates and `PrivilegedVmap` stay zero-sized. Both runners name their platform directly. Neither gains anything it lacked: `litebox_runner_optee_on_linux_userland` already depended on `litebox_platform_linux_userland` with `optee_syscall`, which is what the multiplex feature enabled. `litebox_platform_multiplex` then has no consumers and is deleted, along with its workspace entries, ratchet entry, and `no_std` CI allow-list entry. Globals ratchet: litebox_platform_lvbs 23 (unchanged), litebox_runner_lvbs 6 -> 7 for the session registry, a new entry of 1 for litebox_runner_optee_on_linux_userland, and litebox_platform_multiplex removed.
Sangho Lee (sangho2) pushed a commit
that referenced
this pull request
Jul 29, 2026
`litebox_shim_optee` was hard-wired to `litebox_platform_multiplex::Platform`, so the platform was chosen by cargo feature and fetched from a panicking global. `litebox_platform_lvbs` separately reached itself through `platform_low()`. This parameterizes the shim over its platform, mirroring what #1056 did for `litebox_shim_linux`, and gives LVBS one sanctioned platform accessor. Neither was reachable without first fixing `GlobalVmapManager`. Its `manager()` is a `self`-less method returning `&'static Self::Manager`, so every implementor had to reach a global -- which is the reason both `platform_low()` and `multiplex::platform()` were on the physical-pointer paths. The trait is gone; `PhysMutPtr`/`PhysConstPtr` now hold `mgr: &'m M` and take it at construction. Every construction site outside `litebox_common_linux` is a short-lived local, so the lifetime never escapes a function body. `litebox_shim_optee` is generic over `Platform`, bounded by `OpteeShimPlatform`. The bound includes `VmapManager<PAGE_SIZE>`, so the shim's need to touch normal-world physical memory is stated in the type system rather than implied by the selected platform. The session registry moves to each runner: a `static` cannot name a generic parameter and a shim is built per session, so the shim has nowhere to hold it, while a runner names a concrete platform. `litebox_platform_lvbs` keeps a single instance behind `platform()`, renamed from `platform_low()` and documented as intended rather than as a workaround. A `static` is required regardless -- APs receive only `is_bsp` from the bring-up trampoline -- so the choice was only whether the one instance has one home or many. Caching it in the types that need it was tried and abandoned: it put seven handles to the platform inside the platform's own structs. The three VSM gates and `PrivilegedVmap` stay zero-sized. Both runners name their platform directly. Neither gains anything it lacked: `litebox_runner_optee_on_linux_userland` already depended on `litebox_platform_linux_userland` with `optee_syscall`, which is what the multiplex feature enabled. `litebox_platform_multiplex` then has no consumers and is deleted, along with its workspace entries, ratchet entry, and `no_std` CI allow-list entry. Globals ratchet: litebox_platform_lvbs 23 (unchanged), litebox_runner_lvbs 6 -> 7 for the session registry, a new entry of 1 for litebox_runner_optee_on_linux_userland, and litebox_platform_multiplex removed.
Sangho Lee (sangho2) pushed a commit
that referenced
this pull request
Jul 29, 2026
`litebox_shim_optee` was hard-wired to `litebox_platform_multiplex::Platform`, so the platform was chosen by cargo feature and fetched from a panicking global. `litebox_platform_lvbs` separately reached itself through `platform_low()`. This parameterizes the shim over its platform, mirroring what #1056 did for `litebox_shim_linux`, and gives LVBS one sanctioned platform accessor. Neither was reachable without first fixing `GlobalVmapManager`. Its `manager()` is a `self`-less method returning `&'static Self::Manager`, so every implementor had to reach a global -- which is the reason both `platform_low()` and `multiplex::platform()` were on the physical-pointer paths. The trait is gone; `PhysMutPtr`/`PhysConstPtr` now hold `mgr: &'m M` and take it at construction. Every construction site outside `litebox_common_linux` is a short-lived local, so the lifetime never escapes a function body. `litebox_shim_optee` is generic over `Platform`, bounded by `OpteeShimPlatform`. The bound includes `VmapManager<PAGE_SIZE>`, so the shim's need to touch normal-world physical memory is stated in the type system rather than implied by the selected platform. The session registry moves to each runner: a `static` cannot name a generic parameter and a shim is built per session, so the shim has nowhere to hold it, while a runner names a concrete platform. `litebox_platform_lvbs` keeps a single instance behind `platform()`, renamed from `platform_low()` and documented as intended rather than as a workaround. A `static` is required regardless -- APs receive only `is_bsp` from the bring-up trampoline -- so the choice was only whether the one instance has one home or many. Caching it in the types that need it was tried and abandoned: it put seven handles to the platform inside the platform's own structs. The three VSM gates and `PrivilegedVmap` stay zero-sized. Both runners name their platform directly. Neither gains anything it lacked: `litebox_runner_optee_on_linux_userland` already depended on `litebox_platform_linux_userland` with `optee_syscall`, which is what the multiplex feature enabled. `litebox_platform_multiplex` then has no consumers and is deleted, along with its workspace entries, ratchet entry, and `no_std` CI allow-list entry. Globals ratchet: litebox_platform_lvbs 23 (unchanged), litebox_runner_lvbs 6 -> 7 for the session registry, a new entry of 1 for litebox_runner_optee_on_linux_userland, and litebox_platform_multiplex removed.
Sangho Lee (sangho2) pushed a commit
that referenced
this pull request
Jul 29, 2026
`litebox_shim_optee` was hard-wired to `litebox_platform_multiplex::Platform`, so the platform was chosen by cargo feature and fetched from a panicking global. `litebox_platform_lvbs` separately reached itself through `platform_low()`. This parameterizes the shim over its platform, mirroring what #1056 did for `litebox_shim_linux`, and gives LVBS one sanctioned platform accessor. Neither was reachable without first fixing `GlobalVmapManager`. Its `manager()` is a `self`-less method returning `&'static Self::Manager`, so every implementor had to reach a global -- which is the reason both `platform_low()` and `multiplex::platform()` were on the physical-pointer paths. The trait is gone; `PhysMutPtr`/`PhysConstPtr` now hold `mgr: &'m M` and take it at construction. Every construction site outside `litebox_common_linux` is a short-lived local, so the lifetime never escapes a function body. `litebox_shim_optee` is generic over `Platform`, bounded by `OpteeShimPlatform`. The bound includes `VmapManager<PAGE_SIZE>`, so the shim's need to touch normal-world physical memory is stated in the type system rather than implied by the selected platform. The session registry moves to each runner: a `static` cannot name a generic parameter and a shim is built per session, so the shim has nowhere to hold it, while a runner names a concrete platform. `litebox_platform_lvbs` keeps a single instance behind `platform()`, renamed from `platform_low()` and documented as intended rather than as a workaround. A `static` is required regardless -- APs receive only `is_bsp` from the bring-up trampoline -- so the choice was only whether the one instance has one home or many. Caching it in the types that need it was tried and abandoned: it put seven handles to the platform inside the platform's own structs. The three VSM gates and `PrivilegedVmap` stay zero-sized. Both runners name their platform directly. Neither gains anything it lacked: `litebox_runner_optee_on_linux_userland` already depended on `litebox_platform_linux_userland` with `optee_syscall`, which is what the multiplex feature enabled. `litebox_platform_multiplex` then has no consumers and is deleted, along with its workspace entries, ratchet entry, and `no_std` CI allow-list entry. Globals ratchet: litebox_platform_lvbs 23 (unchanged), litebox_runner_lvbs 6 -> 7 for the session registry, a new entry of 1 for litebox_runner_optee_on_linux_userland, and litebox_platform_multiplex removed.
Sangho Lee (sangho2) pushed a commit
that referenced
this pull request
Jul 29, 2026
The shim was bound to `litebox_platform_multiplex::Platform`, so platform selection happened via cargo features and every platform access went through a panicking global. It is now parameterized end-to-end, mirroring what PR #1056 did for litebox_shim_linux. `OpteeShimPlatform` collects the required capabilities. It includes `VmapManager<PAGE_SIZE>`, which is what the previous two commits bought: the shim's need to read and write normal-world physical memory is now a trait bound rather than a consequence of which platform the build happened to select. Both runners drop the `litebox_platform_multiplex` dependency and name their platform directly. Neither gains anything it did not already have: `litebox_runner_optee_on_linux_userland` already depended on `litebox_platform_linux_userland` with `optee_syscall`, which is exactly what the multiplex `platform_linux_userland_with_optee_syscall` feature was enabling. The session registry moved from the shim to each runner. This is not cosmetic: a `static` cannot name a generic parameter, and a shim instance is built per session, so the shim has nowhere to put it. The composition root names a concrete platform, so it can hold the `static` and hand out `&'static SessionManager<ConcretePlatform>`. `GlobalState` now carries that reference, which is how `current_client_identity` reaches it. Honest accounting of the global ratchet: this relocates globals more than it removes them. litebox_shim_optee stays at 5 (it loses the session registry but its tests gain a platform and a registry, and `INIT_FUNC` goes away). litebox_runner_lvbs goes 6 -> 8: the platform handle and the session registry. litebox_runner_optee_on_linux_userland gets a new entry of 1 for its registry. The platform and shim crates no longer reach for ambient state; the composition roots do, which is where that belongs. `litebox_platform_multiplex` now has zero workspace consumers. It is left in the tree pending a separate decision.
Sangho Lee (sangho2) pushed a commit
that referenced
this pull request
Jul 29, 2026
The shim was bound to `litebox_platform_multiplex::Platform`, so platform selection happened via cargo features and every platform access went through a panicking global. It is now parameterized end-to-end, mirroring what PR #1056 did for litebox_shim_linux. `OpteeShimPlatform` collects the required capabilities. It includes `VmapManager<PAGE_SIZE>`, which is what the previous two commits bought: the shim's need to read and write normal-world physical memory is now a trait bound rather than a consequence of which platform the build happened to select. Both runners drop the `litebox_platform_multiplex` dependency and name their platform directly. Neither gains anything it did not already have: `litebox_runner_optee_on_linux_userland` already depended on `litebox_platform_linux_userland` with `optee_syscall`, which is exactly what the multiplex `platform_linux_userland_with_optee_syscall` feature was enabling. The session registry moved from the shim to each runner. This is not cosmetic: a `static` cannot name a generic parameter, and a shim instance is built per session, so the shim has nowhere to put it. The composition root names a concrete platform, so it can hold the `static` and hand out `&'static SessionManager<ConcretePlatform>`. `GlobalState` now carries that reference, which is how `current_client_identity` reaches it. Honest accounting of the global ratchet: this relocates globals more than it removes them. litebox_shim_optee stays at 5 (it loses the session registry but its tests gain a platform and a registry, and `INIT_FUNC` goes away). litebox_runner_lvbs goes 6 -> 8: the platform handle and the session registry. litebox_runner_optee_on_linux_userland gets a new entry of 1 for its registry. The platform and shim crates no longer reach for ambient state; the composition roots do, which is where that belongs. `litebox_platform_multiplex` now has zero workspace consumers. It is left in the tree pending a separate decision.
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 freeto 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.
The Linux shim was hard-wired to the global
litebox_platform_multiplex::Platformsingleton (set viaset_platform, fetched viaplatform()). This made the shim non-generic and forced platform selection through cargo features. This PR parameterizes the shim over a platform typePlatformend-to-end.