diff --git a/CHANGELOG.md b/CHANGELOG.md index 24aea79c..b0e7f5bc 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,42 @@ Notable user-visible changes are recorded here. SpWKit follows semantic versioning for package releases while the public C ABI remains explicitly versioned through `SPWKIT_API_VERSION_*`. +## v0.7.0 — 2026-09-21 + +Behavioral/backend-contract hardening release. v0.7 defines the software-visible semantics that virtual and future physical providers must preserve, adds requirement-level ECSS SpaceWire software-conformance traceability, and makes performance-regression acceptance an explicit release gate. + +### Added + +- reusable public backend-contract execution for the deterministic DRIVER/reference provider (#211); +- versioned backend behavioral-equivalence matrix `v1-r1` and aggregate proof across SIMULATOR, VSPW-TP/UDP, Linux DEVICE/VSPD and DRIVER (#214); +- project-owned ECSS-E-ST-50-12C Rev.1 applicability/traceability matrix `v0.7-r2`, with seven specifically enumerated `Software verified` requirements and explicit provider/hardware-delegated, not-applicable and not-implemented/future dispositions; +- release-performance comparison tooling against immutable release baselines, repeated hosted screening and controlled same-runner aggregation; +- explicit pre-v1 ECSS-E-ST-40 and ECSS-Q-ST-80 sequencing in the v0.8/v0.9 roadmap. + +### Changed + +- defined and enforced same-handle serialization expectations, distinct-handle concurrency scope, lifecycle behavior, complete-operation timeout semantics, canonical result meanings, bounded-resource semantics and reset-safe zero-copy ownership epochs (#212); +- constrained the represented ECSS time-code profile to six-bit counts with `control_flags == 0`; +- removed duplicate generic packet-shape validation from the LOOPBACK backend after the public core validation path became authoritative; +- retained the zero-copy ownership guard after controlled batched measurement isolated its actual cost at approximately **+2.06 invariant-counter ticks per acquire+release pair**, while a semantics-preserving direct rewrite measured slightly slower; +- aligned package/API versioning and installed consumer requirements on the `0.7` package line. + +### Verification + +- common backend-contract evidence covers copied packet paths, zero-length packets, EOP/EEP, receive capacity retention, time codes, zero-copy interoperability, lifecycle, timeout/error/resource semantics and reset ownership behavior across the applicable backend families; +- controlled v0.7 performance campaigns compare against immutable `v0.6.1` at `03869c0b3bc9e895e0fe61a36f24cff2ace7d527` on matched hosts/toolchains/counters; +- post-cleanup controlled measurements show no recurring LOOPBACK regression, no recurring significant UDP regression, effectively flat DRIVER copied/lifecycle behavior, and DEVICE variation consistent with hosted measurement noise rather than a reproducible source-correlated regression; +- the existing NUCLEO-H755ZI-Q DMA2/Cortex-M7 cache qualification and immutable CCSDSPack `v2.0.0` integration baseline remain part of the provider/integration evidence; +- scoped ECSS conformance claims are backed by executable tests and limited to the requirement rows explicitly marked `Software verified`. + +### Scope + +- SpWKit v0.7.0 conforms to the specifically enumerated ECSS-E-ST-50-12C Rev.1 requirements/subclauses marked `Software verified` in the release matrix for the tested endpoint/link software abstraction; +- physical-layer, encoding, concrete controller/link-engine, flow-control, link-initialization/recovery, electrical and complete node time-code-engine requirements remain delegated to concrete providers/hardware; +- distributed interrupts, standardized node-management parameters and the SpaceWire MIB/service are not part of the v0.7 positive claim and are evaluated before the v1.0 API freeze; +- generic router implementation remains outside the core endpoint/link product scope; +- ECSS-E-ST-40 and ECSS-Q-ST-80 applicability/compliance work is planned for v0.8/v0.9 and is not claimed by v0.7.0. + ## v0.6.1 — 2026-09-10 Maintenance and performance-consolidation release on the v0.6 line. It preserves the existing public application/backend contract while recording the completed profiling infrastructure, accepted performance optimizations, and synchronized post-v0.6 documentation. diff --git a/CMakeLists.txt b/CMakeLists.txt index f847df28..4a145763 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -4,7 +4,7 @@ cmake_minimum_required(VERSION 3.20) # public C ABI and is never required by the runtime implementation. project( spwkit - VERSION 0.6.1 + VERSION 0.7.0 DESCRIPTION "SpaceWire Development & Integration Toolkit" LANGUAGES C ) diff --git a/README.md b/README.md index c92fbd61..7c70e71e 100644 --- a/README.md +++ b/README.md @@ -28,9 +28,9 @@ The runtime is C11. The optional C++17 layer is header-only and forwards to the ## Project status -### Stable: v0.6.1 +### Stable: v0.7.0 -`v0.6.1` is a maintenance and performance-consolidation release on the v0.6 software contract. It preserves the public application/backend API while completing profiling metadata, incorporating accepted transport/readiness optimizations, and synchronizing the post-v0.6 documentation. +`v0.7.0` hardens the software-visible backend contract before the planned v0.8 API/ABI cleanup phase. It defines stable threading, lifecycle, timeout, error, resource, and zero-copy ownership semantics; makes simulator-to-backend behavioral equivalence executable; introduces scoped ECSS-E-ST-50-12C Rev.1 software-conformance traceability; and closes the release with a controlled performance-regression gate against immutable `v0.6.1`. Highlights: @@ -41,20 +41,23 @@ Highlights: - packet EOP/EEP preservation, time codes, link lifecycle/state, readiness, statistics, deterministic timing/fault support, and optional zero-copy ownership; - C11 authoritative runtime with caller-owned/no-heap construction; - optional header-only C++17 consumer layer; -- portable `SPW_BACKEND_DRIVER` callback/configuration contract; +- portable `SPW_BACKEND_DRIVER` callback/configuration contract with a reusable public backend-contract test suite; - DMA-capable driver ownership mapped onto the existing `spw_buffer_t` API; - deterministic reference-driver and freestanding/no-heap evidence; +- explicit same-handle serialization, distinct-handle concurrency, complete-operation timeout, result-code, reset, and zero-copy ownership-epoch semantics; +- versioned `v1-r1` backend behavioral-equivalence evidence across SIMULATOR, VSPW-TP/UDP, Linux DEVICE/VSPD, and DRIVER; +- scoped ECSS-E-ST-50-12C Rev.1 `v0.7-r2` traceability with seven specifically enumerated `Software verified` requirements and explicit delegated/future/not-applicable boundaries; - accepted CCSDSPack `v2.0.0` baseline at `c2f318c330c564429bcc565a8acbff22728b2851`; - CCSDSPack PUS-C TC/TM interoperability over installed-package UDP, Linux DEVICE/VSPD, and a two-node Docker Compose topology; -- physical NUCLEO-H755ZI-Q Cortex-M7 DMA/cache/zero-copy qualification; -- completed profiling host/build/counter metadata and explicit backend coverage classification; -- controlled VSPW-TP 4096-byte RX paired overhead reduction from 60,281 to 25,032 invariant-TSC ticks (58.5%) after reassembly optimization; +- physical NUCLEO-H755ZI-Q Cortex-M7 DMA/cache/zero-copy qualification through the public driver boundary; +- controlled release-performance comparison against immutable `v0.6.1`, including removal of duplicate LOOPBACK validation and quantified retention of the reset-safe zero-copy ownership guard; +- controlled VSPW-TP 4096-byte RX paired overhead reduction from 60,281 to 25,032 invariant-TSC ticks (58.5%) retained from the v0.6 performance work; - POSIX UDP and Linux DEVICE/VSPD optimistic-ready I/O paths that remove avoidable poll-first work while preserving timeout/error semantics; -- Debian/GHCR publication for `amd64`, `arm64`, `armhf`, and `riscv64` hosted targets. +- Debian/GHCR publication support for `amd64`, `arm64`, `armhf`, and `riscv64` hosted targets. -See the [v0.6.1 release notes](docs/releases/v0.6.1.md) and [current project status](docs/current-status.md). +See the [v0.7.0 release notes](docs/releases/v0.7.0.md), [current project status](docs/current-status.md), and [ECSS conformance boundary](docs/ecss-conformance.md). -The v0.6 public boundary deliberately stops before proprietary FPGA/HDL implementation details and before physical SpaceWire PHY/electrical interoperability claims. Hosted profiling values are reference evidence for their named environments, not physical SpaceWire performance specifications. +The public software claim deliberately stops before proprietary FPGA/HDL implementation details and before physical SpaceWire controller/PHY/electrical interoperability claims. Hosted profiling values are reference evidence for their named environments, not physical SpaceWire performance specifications. ## Supported backends @@ -213,7 +216,7 @@ This is real MCU DMA/cache evidence. It is not SpaceWire PHY/electrical HIL. CCSDSPack is an optional upper-layer integration dependency, not a dependency of `libspwkit`. -SpWKit v0.6 pins the interoperability fixture to: +SpWKit v0.7 pins the interoperability fixture to: ```text CCSDSPack v2.0.0 @@ -256,17 +259,17 @@ cmake --build build-freestanding ## Installation and consumers -Stable v0.6 consumers use the exported C target: +Stable v0.7 consumers use the exported C target: ```cmake -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) target_link_libraries(my_app PRIVATE spwkit::spwkit) ``` When the package was built with `SPWKIT_ENABLE_CPP=ON`: ```cmake -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) target_link_libraries(my_cpp_app PRIVATE spwkit::cpp) ``` @@ -274,7 +277,7 @@ Standalone installed-package examples live under `examples/installed*`, distribu ## Binary releases -`v0.6.1` publishes Debian packages for: +`v0.7.0` publishes Debian packages for: ```text amd64 diff --git a/benchmarks/v0.7.0-performance-evidence.md b/benchmarks/v0.7.0-performance-evidence.md index dcb23059..ffb78451 100644 --- a/benchmarks/v0.7.0-performance-evidence.md +++ b/benchmarks/v0.7.0-performance-evidence.md @@ -10,9 +10,21 @@ The primary release baseline is: The runtime candidate measured after the LOOPBACK duplicate-validation cleanup is: -- candidate: `23eceeb0389e02d66febf5a0f027cc3e9153b14a` +- measured runtime candidate: `23eceeb0389e02d66febf5a0f027cc3e9153b14a` -The candidate commit contains the same v0.7 runtime-contract/backend-equivalence implementation as `develop` plus the narrow LOOPBACK hot-path cleanup from PR #226. Documentation-only commits after this measurement do not change the measured runtime source. +The cleanup and evidence were integrated to `develop` by PR #226 at: + +- merged runtime/evidence integration point: `b89ef7871d583923dd58beb9913c1a50a4c9af2d` + +The pre-v1 ECSS roadmap was then merged without runtime changes at: + +- release-preparation base: `aa16b3e9abbf05e8c543e16643d3cf99f8d9189d` + +The v0.7.0 package/API/release-document preparation reached the evidence-freeze point at: + +- release-preparation metadata candidate: `bb2dd94aef8a0cb4aa0ba9e665937e7a637b0b39` + +The commits after `23eceeb0389e02d66febf5a0f027cc3e9153b14a` do not alter the measured runtime implementation. PR #226 integrates that runtime cleanup; the later roadmap/release-preparation changes are documentation, package-version, API-version-macro, and installed-consumer requirement updates. They do not add or modify a runtime hot path. The exact final release-preparation PR head is recorded in #224 after this evidence annotation and its complete CI fan-out are green, avoiding a meaningless self-referential commit-SHA requirement inside the file that defines the final commit. ## Controlled repeated campaign @@ -91,8 +103,8 @@ The original +24-tick per-call observation is retained as useful evidence about ## Release-performance conclusion -The v0.7 candidate has no unexplained reproducible software regression that warrants additional runtime optimization before release. The one attributable new fixed cost, zero-copy RX ownership validation, is approximately two architectural counter ticks per acquire+release pair in the batched probe and is required by the new reset-safe/cross-port ownership semantics. +The v0.7 runtime candidate has no unexplained reproducible software regression that warrants additional runtime optimization before release. The one attributable new fixed cost, zero-copy RX ownership validation, is approximately two architectural counter ticks per acquire+release pair in the batched probe and is required by the new reset-safe/cross-port ownership semantics. PR #226's LOOPBACK cleanup is justified because it removes validation already performed by the public core while preserving backend-specific state, packet-size and resource checks; repeated profiling shows the LOOPBACK path back within normal v0.6.1 variation. -Final release acceptance still requires the post-merge candidate to pass the complete functional/platform/profiling CI suite and the final release-candidate evidence to be frozen before tagging `v0.7.0`. +The final v0.7.0 release-preparation head must pass the complete functional/platform/profiling and release-performance CI suites. #224 records that exact head after those checks complete and is closed before the `v0.7.0` tag may be created. diff --git a/docs/current-status.md b/docs/current-status.md index 0da178a0..a8097792 100644 --- a/docs/current-status.md +++ b/docs/current-status.md @@ -1,10 +1,10 @@ # Current project status -## Stable release: v0.6.1 +## Stable release: v0.7.0 -`v0.6.1` is the current stable release. It is the maintenance/performance consolidation of the v0.6 software contract and preserves the public application-facing `spw_port_*` and backend contract while incorporating the completed profiling infrastructure, accepted readiness/reassembly optimizations, and synchronized documentation. +`v0.7.0` is the current stable software-contract release. It builds on the v0.6 hardware-provider boundary and profiling work by making backend behavior, lifecycle/error/timeout/resource semantics, zero-copy ownership, simulator equivalence, ECSS software-scope conformance, and release-performance acceptance explicit and executable. -The stable v0.6 line includes: +The v0.7 software line includes: - process-local SpaceWire simulation; - VSPW-TP/UDP on POSIX hosts and native Windows/Winsock; @@ -12,35 +12,88 @@ The stable v0.6 line includes: - `spwctl`, `spwmon`, and optional CUSE `/dev/vspwX` presentation; - caller-owned/no-heap construction and optional zero-copy ownership; - public `SPW_BACKEND_DRIVER` configuration/callback contract; +- reusable backend-contract tests for the deterministic DRIVER/reference provider (#211); +- defined threading, lifecycle, timeout, error, resource and reset-safe zero-copy ownership semantics (#212); +- backend behavioral-equivalence matrix `v1-r1` across SIMULATOR, UDP, DEVICE/VSPD and DRIVER (#214); - DMA-capable driver buffer ownership through the existing `spw_buffer_t` API; - deterministic host reference-driver and freestanding/no-heap evidence; - accepted CCSDSPack `v2.0.0` interoperability baseline at commit `c2f318c330c564429bcc565a8acbff22728b2851`; - installed-package PUS-C TC/TM transport over VSPW-TP/UDP and Linux DEVICE/VSPD paths; - deployment-shaped two-node Docker Compose interoperability evidence; - physical NUCLEO-H755ZI-Q Cortex-M7 DMA/cache qualification through the public driver boundary; +- scoped ECSS-E-ST-50-12C Rev.1 software conformance through the `v0.7-r2` traceability matrix; +- controlled performance-regression evidence against immutable `v0.6.1`; - multi-architecture Debian and GHCR publication for `amd64`, `arm64`, `armhf`, and `riscv64` hosted targets. -See [v0.6.1 release notes](releases/v0.6.1.md). +See [v0.7.0 release notes](releases/v0.7.0.md). -## v0.6.1 profiling and performance consolidation +## Runtime and backend contract -v0.6.1 records the post-v0.6 profiling/performance work without intentionally redesigning the public contract. +The v0.7 contract explicitly defines the software-visible behavior that future physical providers must preserve: -Included work: +- overlapping public calls on the same `spw_port_t` are application-serialized; +- distinct handles may be used concurrently, subject to any shared native-controller/provider constraints; +- `stop`, `reset`, and `close` are lifecycle operations rather than asynchronous cancellation primitives; +- zero-copy handles may move between threads only with application synchronization and a single logical owner at a time; +- immediate timeouts perform no deliberate wait, finite timeouts budget the complete public operation, and infinite waits remain terminable by terminal link/backend state; +- canonical result values distinguish argument/state, timeout, unsupported, resource, link, buffer, packet and backend failures; +- reset creates a new zero-copy ownership epoch and stale pre-reset handles are rejected; +- the represented ECSS time-code profile is limited to six-bit counts and `control_flags == 0`. -- hosted and physical STM32 profiling/reference campaigns; -- VSPW-TP reassembly optimization, reducing the isolated fragmented reassembly component by about **96-97%**; -- controlled 4096-byte VSPW-TP RX paired overhead reduction from **60,281 to 25,032 TSC ticks** (**58.5%**); -- POSIX UDP optimistic-ready I/O, removing unconditional poll-first work where `MSG_DONTWAIT` is available; -- Linux DEVICE/VSPD optimistic-ready record I/O, saving roughly **813-850 TSC ticks** in the hosted paired readiness microbenchmark and reducing the raw operation by about **41-51%**; -- finalized profiling host/build/counter metadata and backend coverage classification from #171/#173; -- synchronized release/evidence documentation from #208. +The common backend-contract suite is reused across SIMULATOR, VSPW-TP/UDP, Linux DEVICE/VSPD and the reference DRIVER. Behavioral equivalence concerns application-visible semantics; it does not assert timing equivalence with physical SpaceWire hardware. -Hosted timing results are reference/regression evidence for the named measurement environment. They are not physical SpaceWire controller, PHY, cable, or universal performance specifications. +## ECSS SpaceWire conformance policy + +SpWKit targets **ECSS-E-ST-50-12C Rev.1** within the limits of the endpoint/link software abstraction implemented by this repository. + +The v0.7 release maintains a project-owned applicability/traceability matrix at `tests/compliance/ecss-e-st-50-12c-rev1.md`, revision `v0.7-r2`. Positive conformance claims apply only to the specifically enumerated rows classified **Software verified**. + +The current positive software claim covers seven mapped requirements concerning: + +- EOP/EEP packet termination preservation; +- zero-data packets; +- transparent packet cargo; +- endpoint packet send/receive service semantics; +- the represented time-code specialization/type; +- six-bit time-code count values; +- endpoint time-code service semantics when the capability is advertised. + +The matrix separately records requirements that are: + +- implemented and verified by SpWKit software; +- delegated to a concrete hardware/provider implementation; +- not applicable to the endpoint/link scope; +- applicable software capabilities not yet implemented and therefore not claimed. + +Physical-layer, encoding, concrete controller/link-engine, flow-control, link-initialization/recovery, electrical and complete node time-code-engine requirements remain provider/hardware responsibilities. The private `spwkit-fpga` project owns the applicable ExoSpaceLabs FPGA/controller/PHY evidence. Full end-to-end SpaceWire conformance for a concrete system requires evidence from both layers. + +Distributed interrupts, standardized node-management parameters and the SpaceWire MIB/service remain outside the v0.7 positive claim. Their pre-v1 disposition is recorded in the roadmap. Generic router implementation remains outside the core SpWKit product scope. + +See [`ecss-conformance.md`](ecss-conformance.md) and the [traceability matrix](../tests/compliance/ecss-e-st-50-12c-rev1.md). + +## v0.7.0 release-performance gate + +The immutable comparison baseline is `v0.6.1` at `03869c0b3bc9e895e0fe61a36f24cff2ace7d527`. + +The release-performance tooling performs paired baseline/candidate measurement and repeated-screen aggregation. Controlled same-runner measurements were then used to distinguish reproducible software changes from hosted counter/scheduler noise. + +The final investigation established: + +- duplicate generic packet-shape validation in LOOPBACK was avoidable after validation became authoritative in the public core path and was removed before release; +- controlled post-cleanup measurements show no recurring LOOPBACK regression; +- DRIVER copied paths and lifecycle measurements remain effectively flat; +- no recurring significant UDP regression was reproduced in the controlled campaign; +- Linux DEVICE measurements showed large hosted-runner variance/sign changes rather than a stable source-correlated regression; +- an apparent RX zero-copy release plateau was traced to per-call counter-floor quantization; a batched 2,000,000-pair probe isolated the actual reset-safe ownership guard cost at approximately **+2.06 invariant-counter ticks per acquire+release pair**; +- a semantics-preserving direct rewrite was slightly slower, so the required ownership protection is retained unchanged. + +No unexplained reproducible software regression remains that warrants additional runtime optimization before v0.7.0. Hosted timing values remain regression/reference evidence for their named environment, not physical SpaceWire performance claims. + +See [`../benchmarks/v0.7.0-performance-evidence.md`](../benchmarks/v0.7.0-performance-evidence.md) and [`../benchmarks/RELEASE_PERFORMANCE.md`](../benchmarks/RELEASE_PERFORMANCE.md). ## STM32H755 qualification -The phase-7 physical-board run completed successfully with: +The existing physical-board evidence remains part of the provider-contract foundation: ```text magic = 0x53505736 @@ -59,22 +112,22 @@ This validates real STM32 DMA2 execution, Cortex-M7 cache clean/invalidate owner ## Profiling reference -The profiling campaign provides reproducible software/provider performance evidence on top of the v0.6 functional boundary: +The profiling infrastructure retains the v0.6/v0.7 software/provider performance evidence: -- controlled i7-1355U hosted DRIVER/native differential and copied-vs-zero-copy crossover characterization; -- complete hosted LOOPBACK, SIMULATOR, VSPW-TP/UDP and DEVICE/VSPD boundary instrumentation; +- controlled hosted DRIVER/native differential and copied-vs-zero-copy characterization; +- complete LOOPBACK, SIMULATOR, VSPW-TP/UDP and DEVICE/VSPD boundary instrumentation; - NUCLEO-H755ZI-Q Cortex-M7 DWT measurements for copied and zero-copy DMA-provider paths; - matched STM32H755 direct/native DMA2 differential measurements; -- controlled lifecycle/startup measurements kept separate from steady-state TX/RX data; -- controlled VSPW-TP stage attribution followed by the accepted reassembly optimization; -- POSIX UDP and Linux DEVICE/VSPD readiness-path optimization with equivalent-path comparator checks; -- campaign metadata covering host/build/counter context and explicit backend coverage states (`measured`, `unsupported-platform`, `not-built`, `not-implemented-benchmark`). +- lifecycle/startup measurements kept separate from steady-state TX/RX data; +- VSPW-TP stage attribution and the accepted reassembly optimization; +- POSIX UDP and Linux DEVICE/VSPD readiness-path optimization; +- campaign metadata covering host/build/counter context and explicit backend coverage states. -The canonical measurement contract and interpretation limits are documented in [`profiling.md`](profiling.md). The accepted statistics and measured before/after achievements are summarized in [`profiling-results.md`](profiling-results.md). Hosted x86 values are reported as invariant TSC ticks; Cortex-M7 values are DWT cycles. Neither virtual transport nor generic STM32 DMA evidence is presented as SpaceWire controller/PHY/link timing. +The canonical interpretation limits are documented in [`profiling.md`](profiling.md) and [`profiling-results.md`](profiling-results.md). Hosted x86 values are invariant TSC/counter ticks; Cortex-M7 values are DWT cycles. Neither virtual transport nor generic STM32 DMA evidence is presented as SpaceWire controller/PHY/link timing. ## CCSDSPack integration baseline -SpWKit v0.6 accepts the immutable external integration reference: +SpWKit v0.7 retains the immutable external integration reference: - tag: `CCSDSPack v2.0.0`; - commit: `c2f318c330c564429bcc565a8acbff22728b2851`. @@ -85,63 +138,23 @@ CCSDSPack remains optional and external. `libspwkit` does not include or link CC The public repository defines the portable driver semantics and generic HIL acceptance criteria. It does not publish proprietary FPGA/HDL implementation details, register maps, descriptor layouts, bus/clock/reset/interrupt architecture, or electrical design. -Physical FPGA-backed SpaceWire interoperability remains a later validation layer described in [`hardware-acceptance.md`](hardware-acceptance.md). - -## v0.7 development status - -The planned v0.7 behavioral/backend-contract engineering scope is now implemented on `develop`: - -- the deterministic DRIVER/reference provider executes the reusable public backend contract (#211); -- the stable threading, lifecycle, error, timeout, resource and zero-copy ownership semantics are defined and executable (#212); -- the simulator-to-backend behavioral-equivalence matrix and aggregate proof are implemented across SIMULATOR, UDP, DEVICE/VSPD and DRIVER (#214). - -This does **not** yet make `v0.7.0` a released version. Final publication is gated by #224. - -## ECSS SpaceWire conformance policy - -SpWKit targets **ECSS-E-ST-50-12C Rev.1** within the limits of the endpoint/link software abstraction implemented by this repository. - -The v0.7 release candidate now maintains a project-owned applicability/traceability matrix (`tests/compliance/ecss-e-st-50-12c-rev1.md`, revision `v0.7-r2`). It makes positive conformance claims only for the specifically enumerated rows classified **Software verified**. The matrix separately records: - -- software requirements implemented and verified by SpWKit; -- requirements delegated to a concrete hardware/provider implementation; -- requirements that are not applicable to the SpWKit endpoint/link scope; -- applicable software capabilities that are not yet implemented and therefore are not claimed. - -The current positive software claim covers specifically mapped packet/EOP/EEP/cargo service semantics plus the represented time-code type/value and endpoint time-code service primitive. It does not claim the complete concrete-node time-code register/master/sequence-propagation machinery. - -The private `spwkit-fpga` project is responsible for the FPGA/controller/PHY/electrical and other concrete-node conformance evidence that belongs below the public DRIVER boundary. Full end-to-end SpaceWire conformance for a concrete system requires the applicable evidence from both layers. - -See [`ecss-conformance.md`](ecss-conformance.md), the [traceability matrix](../tests/compliance/ecss-e-st-50-12c-rev1.md), and #224. - -## v0.7.0 release quality gate - -Before `v0.7.0` is tagged, the release candidate must satisfy both the software-scope ECSS traceability gate and a performance-regression gate against immutable `v0.6.1`. - -The release-performance tooling now performs paired baseline/candidate measurement and supports repeated-screen aggregation. GitHub-hosted CI executes three independent shortened paired screens and classifies only recurring positive threshold crossings as targets for controlled-host investigation. Hosted repetition remains screening evidence; final acceptance requires repeated measurements on one controlled host using the same machine/toolchain/governor policy. - -Any v0.7 change that can affect a hot path or lifecycle cost must be measured using the existing controlled profiling infrastructure. Reproducible regressions outside normal measurement noise are investigated; avoidable overhead is optimized before release. A regression may be accepted only when it is a necessary correctness/semantic tradeoff, is quantified, and is documented. - -Known avoidable release-candidate work is not intentionally deferred to `v0.7.1`. Patch releases remain available for defects discovered after publication, not as a substitute for completing the release candidate. - -See [`../benchmarks/RELEASE_PERFORMANCE.md`](../benchmarks/RELEASE_PERFORMANCE.md) for the release-performance procedure. +Physical FPGA-backed SpaceWire interoperability remains a later validation layer described in [`hardware-acceptance.md`](hardware-acceptance.md). Introducing a conforming physical provider is not intended to require redesign of the application-facing `spw_port_*` logic. ## Road to v1.0 -The v1.0 objective is a stable software-facing API/backend contract that external applications and future hardware providers can depend on without redesigning the application layer. FPGA RTL, USB adapters, ASICs, router implementation and optional upper layers do not block the generic software release boundary. Software-scope ECSS conformance remains an explicit requirement; physical/provider conformance is evidenced by the corresponding provider implementation. - -The planned progression is evidence-driven: +The v1.0 objective is a stable software-facing API/backend contract that external applications and future hardware providers can depend on without redesigning the application layer. ```text -v0.6.1 profiling/performance consolidation and documentation sync -v0.7.x behavioral/backend contract hardening and simulator equivalence -v0.8.x public API/ABI cleanup and DRIVER contract candidate -v0.9.x API freeze, compatibility gates, fuzz/soak and 1.0 RC -v1.0.0 stable software contract +v0.7.0 behavioral/backend contract + ECSS SpaceWire software scope + performance gate +v0.8.x public API/ABI cleanup, DRIVER contract candidate, ECSS-E-ST-40 applicability/API-impact work +v0.9.x API freeze, ECSS-E-ST-40/Q-ST-80 evidence hardening, compatibility gates, fuzz/soak, 1.0 RC +v1.0.0 stable software contract and documented standards applicability/compliance status ``` -See #209 and its tracked workstreams #210-#216 plus the v0.7 release gate #224 for the pre-v1 contract-hardening plan. +During v0.8, distributed interrupts, standardized node-management parameters and SpaceWire MIB/service are evaluated before API freeze. Routing remains outside the core endpoint/link scope unless the project deliberately changes that architecture. + +See #209 and workstreams #210-#216 plus [`roadmap.md`](roadmap.md). -## Development flow after v0.6.1 +## Development flow after v0.7.0 -`main` tracks stable releases and `develop` remains the integration branch for subsequent work. No post-v0.6.1 feature is considered delivered until it has its own implementation and evidence boundary. +`main` tracks stable releases and `develop` remains the integration branch for subsequent work. Temporary release/feature branches are deleted after integration; immutable tags and release artifacts preserve release history. diff --git a/docs/getting-started.md b/docs/getting-started.md index a8ad1d3c..1c4132bf 100644 --- a/docs/getting-started.md +++ b/docs/getting-started.md @@ -1,6 +1,6 @@ # Getting started -This guide targets the current stable `v0.6.1` release. v0.6.1 preserves the v0.6 public application/backend contract while consolidating the completed profiling/performance work and documentation. +This guide targets the current stable `v0.7.0` release. v0.7.0 hardens the software-visible backend contract, behavioral equivalence, ECSS SpaceWire software-conformance traceability, and release-performance evidence before the planned v0.8 API/ABI cleanup phase. ## Choose how you want to run SpaceWire software @@ -15,12 +15,12 @@ flowchart TD NODE -->|yes| CUSE[spwcuse] NODE -->|no| API[Use spw_port_*] START --> HW{Hardware/RTOS integration?} - HW --> DRIVER[SPW_BACKEND_DRIVER
v0.6 stable] + HW --> DRIVER[SPW_BACKEND_DRIVER
v0.7 stable] ``` For ordinary application development, start with the copied packet API. Zero-copy is an optional capability that can be introduced later without changing packet semantics. -On `develop`, the candidate v1-r1 [backend behavioral-equivalence matrix](backend-equivalence.md) makes this development path explicit: application packet/link logic validated against the simulator is exercised by the same shared contract against UDP, Linux DEVICE/VSPD and the deterministic DRIVER provider. Backend setup changes; the portable SpaceWire-facing API and documented semantics do not. +The v1-r1 [backend behavioral-equivalence matrix](backend-equivalence.md) makes this development path explicit: application packet/link logic validated against the simulator is exercised by the same shared contract against UDP, Linux DEVICE/VSPD and the deterministic DRIVER provider. Backend setup changes; the portable SpaceWire-facing API and documented semantics do not. ## Build from source @@ -44,9 +44,9 @@ cmake -S . -B build-cpp \ cmake --build build-cpp --parallel ``` -## Install the stable v0.6 package +## Install the stable v0.7 package -`v0.6.1` publishes Debian revision `0.6.1-1` for: +`v0.7.0` publishes Debian revision `0.7.0-1` for: ```text amd64 @@ -58,10 +58,10 @@ riscv64 Example package names: ```text -spwkit_0.6.1-1_amd64.deb -spwkit_0.6.1-1_arm64.deb -spwkit_0.6.1-1_armhf.deb -spwkit_0.6.1-1_riscv64.deb +spwkit_0.7.0-1_amd64.deb +spwkit_0.7.0-1_arm64.deb +spwkit_0.7.0-1_armhf.deb +spwkit_0.7.0-1_riscv64.deb ``` Stable GHCR images are also published for `linux/amd64`, `linux/arm64`, `linux/arm/v7`, and `linux/riscv64`. See [binary packages](binary-packages.md). @@ -172,7 +172,7 @@ flowchart LR REC --> REL[Release or reuse] ``` -The simulator provides a deterministic software implementation of this ownership contract. The v0.6 driver backend maps the same API onto driver/DMA buffers. +The simulator provides a deterministic software implementation of this ownership contract. The v0.7 driver backend maps the same API onto driver/DMA buffers and enforces reset-safe ownership epochs. ## Run distributed virtual SpaceWire @@ -211,7 +211,7 @@ Applications attach through `SPW_BACKEND_DEVICE`. `spwctl` inspects/manages daem ### Optional `/dev/vspwX` -The stable v0.6 line includes `spwcuse` for applications that need a real Linux character device: +The stable v0.7 line includes `spwcuse` for applications that need a real Linux character device: ```bash cmake -S . -B build-cuse \ @@ -241,26 +241,26 @@ With `SPWKIT_ENABLE_HEAP=OFF`, `spw_port_open()` is not the construction path; u HardRT `0.4.0` is the currently validated external RTOS baseline. The Cortex-M7 CI fixture is compile/link evidence; a separate physical NUCLEO-H755ZI-Q qualification has also completed using real DMA2 and explicit Cortex-M7 cache synchronization through the public driver boundary. Neither result is physical SpaceWire PHY/electrical HIL. -## v0.6 driver backend +## v0.7 driver backend -Stable `v0.6.1` includes `SPW_BACKEND_DRIVER` and its DMA/ownership callback boundary. It is intended for host reference drivers, MCU/RTOS integrations and future FPGA/vendor controllers while keeping application source on the same `spw_port_*`/`spw_buffer_*` API. +Stable `v0.7.0` includes `SPW_BACKEND_DRIVER`, its DMA/ownership callback boundary, and the reusable public backend-contract evidence. It is intended for host reference drivers, MCU/RTOS integrations and future FPGA/vendor controllers while keeping application source on the same `spw_port_*`/`spw_buffer_*` API. -The physical STM32H755 DMA/cache qualification has completed successfully and validates the software ownership/cache boundary on real Cortex-M7 silicon. It does not prove a physical SpaceWire controller, codec, PHY or cable; FPGA/SpaceWire HIL remains a separate future evidence layer. +The physical STM32H755 DMA/cache qualification validates the software ownership/cache boundary on real Cortex-M7 silicon. It does not prove a physical SpaceWire controller, codec, PHY or cable; FPGA/SpaceWire HIL remains a separate future evidence layer. ## Consume the installed package C: ```cmake -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) target_link_libraries(my_app PRIVATE spwkit::spwkit) ``` C++17 wrapper: ```cmake -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) target_link_libraries(my_app PRIVATE spwkit::cpp) ``` -The stable v0.6 package examples request the compatible `0.6` line. v0.6.1 does not intentionally change that public compatibility contract. +The stable v0.7 package examples request the compatible `0.7` line. `v0.7.0` is the immutable release evidence boundary for this package line. diff --git a/docs/language-bindings.md b/docs/language-bindings.md index f99da9bf..b4d1483e 100644 --- a/docs/language-bindings.md +++ b/docs/language-bindings.md @@ -109,20 +109,20 @@ A pure-C consumer can use `CXX=/bin/false`. The optional wrapper target is insta C consumer: ```cmake -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) target_link_libraries(app PRIVATE spwkit::spwkit) ``` C++ wrapper consumer: ```cmake -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) target_link_libraries(app PRIVATE spwkit::cpp) ``` ## Platform/backend behavior -The wrapper does not create platform-specific behavior. `SPW_BACKEND_UDP` uses POSIX sockets or Winsock beneath the same C API; `SPW_BACKEND_DEVICE` remains Linux-specific; stable v0.6.1 `SPW_BACKEND_DRIVER` is portable to hosted and embedded targets according to the selected driver implementation. +The wrapper does not create platform-specific behavior. `SPW_BACKEND_UDP` uses POSIX sockets or Winsock beneath the same C API; `SPW_BACKEND_DEVICE` remains Linux-specific; stable v0.7.0 `SPW_BACKEND_DRIVER` is portable to hosted and embedded targets according to the selected driver implementation. A wrapper method may therefore return `SPW_ERR_UNSUPPORTED` for a capability or backend that is unavailable in the selected build, exactly as the C call would. diff --git a/docs/releases/v0.7.0.md b/docs/releases/v0.7.0.md new file mode 100644 index 00000000..3a84da6a --- /dev/null +++ b/docs/releases/v0.7.0.md @@ -0,0 +1,89 @@ +# SpWKit v0.7.0 + +Release date: 2026-09-21 + +SpWKit v0.7.0 hardens the software-visible SpaceWire contract before the planned v0.8 API/ABI cleanup phase. The release makes backend behavior, lifecycle/error/timeout/resource semantics, simulator equivalence, ECSS software-scope conformance, and release-performance acceptance explicit and executable. + +## Highlights + +- reusable public backend-contract evidence for the deterministic DRIVER/reference provider (#211); +- stable threading, lifecycle, timeout, result, resource, and zero-copy ownership/reset semantics (#212); +- versioned backend behavioral-equivalence matrix across SIMULATOR, VSPW-TP/UDP, Linux DEVICE/VSPD, and DRIVER (#214); +- scoped ECSS-E-ST-50-12C Rev.1 software conformance with requirement-level traceability and an explicit provider/hardware boundary; +- release-performance comparison against immutable v0.6.1, including repeated same-runner measurements and source-level investigation of reproducible hot-path differences; +- removal of duplicate LOOPBACK packet-shape validation after the common public API contract became authoritative; +- quantified retention of the reset-safe zero-copy ownership guard after batched measurement isolated its real cost at approximately 2.06 invariant-counter ticks per acquire+release pair; +- explicit v0.8/v0.9 ECSS-E-ST-40 and ECSS-Q-ST-80 roadmap sequencing before the v1.0 contract freeze. + +## Runtime contract + +The v0.7 public contract now states and tests the following behavior: + +- applications serialize overlapping operations on the same `spw_port_t`; distinct handles may be used concurrently subject to provider/controller constraints; +- `stop`, `reset`, and `close` are lifecycle operations and are not asynchronous cancellation primitives; +- zero-copy handles may cross threads only with application synchronization and one logical owner at a time; +- immediate timeouts perform no deliberate wait, finite timeouts budget the complete public operation, and infinite waits remain interruptible by terminal link/backend state; +- public result values have defined meanings for invalid arguments/state, timeout, unsupported capability, resource exhaustion, link unavailability, buffer size, invalid packets, and backend failures; +- reset creates a new zero-copy ownership epoch and stale pre-reset handles are rejected; +- supported time-code values remain six-bit counts and the currently represented ECSS time-code specialization requires `control_flags == 0`. + +## Backend equivalence + +The release includes the versioned `v1-r1` behavioral-equivalence matrix and a common executable backend contract. The aggregate test exercises: + +- process-local SIMULATOR; +- VSPW-TP/UDP; +- Linux DEVICE/VSPD; +- deterministic DRIVER/reference provider. + +Virtual-backend behavioral equivalence means equivalent software-visible packet, lifecycle, timeout, error, ownership, and supported time-code semantics. It does not claim timing equivalence with physical SpaceWire hardware. + +## ECSS-E-ST-50-12C Rev.1 software conformance + +The release traceability matrix is `tests/compliance/ecss-e-st-50-12c-rev1.md`, revision `v0.7-r2`. + +SpWKit v0.7.0 conforms to the specifically enumerated ECSS-E-ST-50-12C Rev.1 requirements/subclauses marked **Software verified** in that matrix for the tested endpoint/link software abstraction. + +The positive software claim currently covers seven mapped requirements concerning: + +- EOP/EEP packet termination preservation; +- zero-data packets; +- transparent packet cargo; +- endpoint packet send/receive service semantics; +- the supported time-code specialization/type; +- six-bit time-code count values; +- endpoint time-code service semantics when the capability is advertised. + +Physical-layer, encoding, concrete link-engine, link initialization/recovery, flow-control, electrical, and complete node time-code-engine requirements remain delegated to the concrete provider/hardware implementation. For the ExoSpaceLabs physical path, applicable controller/PHY evidence belongs to `spwkit-fpga` or its later physical replacement. + +Distributed interrupts, standardized node-management parameters, and the SpaceWire MIB/service remain explicitly outside the v0.7 positive claim and are evaluated in the pre-v1 roadmap. Router implementation remains outside the core endpoint/link scope. + +## Performance acceptance + +The immutable performance baseline is v0.6.1 at commit `03869c0b3bc9e895e0fe61a36f24cff2ace7d527`. + +The v0.7 campaign used matched baseline/candidate public-operation and native-relative measurements, repeated hosted screening, and controlled same-runner measurements. The investigation found: + +- no recurring unexplained LOOPBACK regression after removing duplicate backend packet-shape validation; +- no recurring significant UDP regression in the controlled campaign; +- copied DRIVER and lifecycle measurements remained effectively flat; +- Linux DEVICE measurements showed substantial hosted-runner noise and sign changes rather than a stable software regression; +- the apparent per-call RX zero-copy release plateau was dominated by measurement-floor quantization; a 2,000,000-pair batched probe isolated the reset-safe ownership guard at approximately +2.06 ticks per acquire+release pair; +- a semantics-preserving direct rewrite was slightly slower than the retained implementation, so the ownership protection remains unchanged. + +No unexplained reproducible software regression remains that warrants additional runtime optimization before v0.7.0. Hosted counter measurements are regression/reference evidence for their named environment, not physical SpaceWire timing specifications. + +See `benchmarks/v0.7.0-performance-evidence.md` and `benchmarks/RELEASE_PERFORMANCE.md` for the evidence boundary and procedure. + +## Compatibility and scope + +v0.7.0 intentionally strengthens behavioral semantics while remaining on the pre-v1 API line. The major public API/ABI cleanup remains scheduled for v0.8, followed by the v0.9 freeze and 1.0 release-candidate phase. + +This release does not claim: + +- physical FPGA-backed SpaceWire electrical/PHY interoperability; +- router implementation; +- complete ECSS node-management, distributed-interrupt, or MIB services; +- ECSS-E-ST-40 or ECSS-Q-ST-80 compliance. Their applicability/evidence work is explicitly scheduled for v0.8/v0.9. + +The application-facing design goal remains unchanged: moving from virtual backends to a conforming physical provider must not require redesigning SpaceWire-facing application logic. diff --git a/docs/roadmap.md b/docs/roadmap.md index 3fbe5c56..a8334d5a 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -82,27 +82,22 @@ Consolidated the v0.6 contract as a patch release without an intentional public - synchronized package, testing, profiling and hardware-evidence documentation; - published immutable `v0.6.1` source, multi-architecture Debian packages and the multi-architecture GHCR image through the release-policy workflow. -## v0.7.0 release candidate +### v0.7.0 -The behavioral/backend-contract engineering planned for v0.7 is implemented on `develop`: +Hardened the software-visible behavioral/backend contract before the planned v0.8 API/ABI cleanup phase: - the deterministic DRIVER/reference provider executes the reusable public backend contract (#211); - threading, lifecycle, error, timeout, resource and zero-copy reset/ownership semantics are defined and enforced (#212); -- simulator-to-backend behavioral equivalence is versioned and executable across SIMULATOR, VSPW-TP/UDP, Linux DEVICE/VSPD and DRIVER (#214). +- simulator-to-backend behavioral equivalence is versioned and executable across SIMULATOR, VSPW-TP/UDP, Linux DEVICE/VSPD and DRIVER (#214); +- ECSS-E-ST-50-12C Rev.1 has a project-owned `v0.7-r2` applicability/traceability matrix with specifically enumerated positive software claims and explicit delegated/future/not-applicable dispositions; +- concrete controller/PHY/electrical and complete node time-code-engine requirements are delegated explicitly to the provider, with `spwkit-fpga` responsible for its applicable hardware-side evidence; +- release-performance tooling compares immutable `v0.6.1` with the candidate using matched public-operation/native-relative metrics and separate lifecycle evidence; +- repeated hosted and same-runner campaigns distinguish reproducible regressions from counter/scheduler noise; +- avoidable LOOPBACK duplicate validation was removed before release, while the reset-safe zero-copy ownership guard was retained after its real cost was isolated at approximately two architectural counter ticks per acquire+release pair. -`v0.7.0` is not considered complete merely because those functional changes pass CI. Publication is gated by #224. +A performance regression is accepted only when it is a necessary correctness/semantic tradeoff, quantified and documented. Known avoidable release-candidate cleanup is not intentionally deferred to a patch release merely because a patch number is available. -The release gate is implemented as project-owned evidence/tooling: - -1. ECSS-E-ST-50-12C Rev.1 has a project-owned `v0.7-r2` applicability/traceability matrix with specifically enumerated positive software claims and explicit delegated/future/not-applicable dispositions; -2. concrete controller/PHY/electrical and complete node time-code-engine requirements are delegated explicitly to the provider, with `spwkit-fpga` responsible for its applicable hardware-side evidence; -3. release-performance tooling compares immutable `v0.6.1` with the candidate using matched public-operation/native-relative metrics and separate lifecycle evidence; -4. repeated hosted and same-runner campaigns are used to distinguish reproducible regressions from counter/scheduler noise; -5. avoidable LOOPBACK duplicate validation was removed before release, while the reset-safe zero-copy ownership guard was retained after its real cost was isolated at approximately two architectural counter ticks per acquire+release pair. - -A performance regression is accepted only when it is a necessary correctness/semantic tradeoff, quantified and documented. Known avoidable release-candidate cleanup is not intentionally deferred to `v0.7.1` simply because a patch number is available. - -See [`ecss-conformance.md`](ecss-conformance.md) for the software/provider conformance boundary and [`../benchmarks/RELEASE_PERFORMANCE.md`](../benchmarks/RELEASE_PERFORMANCE.md) for the performance gate. +Release tagging remains governed by the exact-candidate evidence gate in #224 and the repository release-policy workflow. See [`ecss-conformance.md`](ecss-conformance.md) for the software/provider conformance boundary and [`../benchmarks/v0.7.0-performance-evidence.md`](../benchmarks/v0.7.0-performance-evidence.md) for the performance acceptance record. ## v0.8.x contract and ECSS architecture phase diff --git a/docs/testing.md b/docs/testing.md index 29ac7059..b75d9517 100644 --- a/docs/testing.md +++ b/docs/testing.md @@ -142,7 +142,7 @@ The namespace topology uses a real veth/IP boundary. Compose adds deployment-sha ## CCSDSPack integration -The v0.6 integration builds CCSDSPack and SpWKit as independent installed packages and verifies byte-exact PUS-C TC/TM exchange over SpWKit. +The v0.7 integration builds CCSDSPack and SpWKit as independent installed packages and verifies byte-exact PUS-C TC/TM exchange over SpWKit. The consolidated CI gate independently checks out immutable CCSDSPack `v2.0.0`, verifies commit `c2f318c330c564429bcc565a8acbff22728b2851`, builds both installed packages separately, and executes the UDP peer exchange. A moving `CCSDSPack/develop` branch is not release evidence. @@ -165,7 +165,7 @@ VSPD/`vspwd` verification covers: ## CUSE -The early `cuse-feasibility.md` work is retained as a historical design record. v0.5 subsequently shipped production `spwcuse`, and the stable v0.6 line retains it. CI includes a live `/dev/cuse` character-device contract where the runner exposes CUSE. +The early `cuse-feasibility.md` work is retained as a historical design record. v0.5 shipped production `spwcuse`, and the stable v0.7 line retains it. CI includes a live `/dev/cuse` character-device contract where the runner exposes CUSE. The contract checks packet-record behavior, DATA/EOP/EEP/time codes, zero-length packets, non-consuming short reads, non-blocking empty reads, poll/readiness and endpoint ownership. @@ -173,12 +173,12 @@ CUSE/libfuse remains outside the public `libspwkit` ABI. ## Driver / DMA -The stable v0.6 line verifies: +The stable v0.7 line verifies: - required callback/capability consistency; - lifecycle and copied DATA mapping; - zero-copy DMA acquire/submit/reclaim/release; -- pointer/ownership transitions; +- pointer/ownership transitions and reset-safe ownership epochs; - cache hook ordering; - stale/foreign token rejection; - bounded wrapper slots; @@ -213,18 +213,18 @@ The HIL workflow remains explicit/manual and must not be satisfied by hosted sim Consumers are configured as independent projects using exported targets only: ```cmake -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) target_link_libraries(c_app PRIVATE spwkit::spwkit) ``` Optional C++: ```cmake -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) target_link_libraries(cpp_app PRIVATE spwkit::cpp) ``` -Stable v0.6.1 remains compatible with consumers requesting the v0.6 package line. Subsequent work belongs on `develop`; the immutable v0.6.1 tag remains the release evidence boundary. +Stable v0.7.0 consumers request the v0.7 package line. The immutable v0.7.0 tag is the release evidence boundary for that package version. ## Determinism rules @@ -237,4 +237,4 @@ Stable v0.6.1 remains compatible with consumers requesting the v0.6 package line ## Compliance evidence -Automated tests are engineering evidence, not automatic ECSS certification. Electrical, Data-Strobe, exact timing and physical interoperability requirements remain outside packet-level software simulation and require corresponding hardware verification. +Automated tests are engineering evidence supporting the explicitly scoped software-conformance matrix; they are not automatic whole-system ECSS certification. Electrical, Data-Strobe, exact timing and physical interoperability requirements remain outside packet-level software simulation and require corresponding hardware verification. diff --git a/examples/distributed/CMakeLists.txt b/examples/distributed/CMakeLists.txt index a44e5cca..87a85c7e 100644 --- a/examples/distributed/CMakeLists.txt +++ b/examples/distributed/CMakeLists.txt @@ -5,7 +5,7 @@ if(NOT UNIX) message(FATAL_ERROR "This C distributed example currently requires a POSIX host for its nanosleep-based wait helper") endif() -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) if(NOT SpWKit_UDP_RUNTIME_SUPPORTED) message(FATAL_ERROR "Installed SpWKit package does not provide the UDP runtime") diff --git a/examples/distributed_cpp/CMakeLists.txt b/examples/distributed_cpp/CMakeLists.txt index a2515b5b..8cf65711 100644 --- a/examples/distributed_cpp/CMakeLists.txt +++ b/examples/distributed_cpp/CMakeLists.txt @@ -1,7 +1,7 @@ cmake_minimum_required(VERSION 3.20) project(spwkit_distributed_cpp_peer LANGUAGES CXX) -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) if(NOT SpWKit_UDP_RUNTIME_SUPPORTED) message(FATAL_ERROR "Installed SpWKit package does not provide the UDP runtime") diff --git a/examples/installed/CMakeLists.txt b/examples/installed/CMakeLists.txt index e00d6b27..558cbb47 100644 --- a/examples/installed/CMakeLists.txt +++ b/examples/installed/CMakeLists.txt @@ -2,7 +2,7 @@ cmake_minimum_required(VERSION 3.20) project(spwkit_installed_consumer LANGUAGES C) include(CTest) -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) if(NOT DEFINED SpWKit_UDP_RUNTIME_SUPPORTED) message(FATAL_ERROR "Installed SpWKit package does not declare UDP runtime availability") @@ -34,4 +34,4 @@ set_target_properties(spwkit_installed_consumer PROPERTIES C_STANDARD_REQUIRED YES ) -add_test(NAME installed_package_consumer COMMAND spwkit_installed_consumer) \ No newline at end of file +add_test(NAME installed_package_consumer COMMAND spwkit_installed_consumer) diff --git a/examples/installed_cpp/CMakeLists.txt b/examples/installed_cpp/CMakeLists.txt index 533ff054..439c7932 100644 --- a/examples/installed_cpp/CMakeLists.txt +++ b/examples/installed_cpp/CMakeLists.txt @@ -2,7 +2,7 @@ cmake_minimum_required(VERSION 3.20) project(spwkit_installed_cpp_consumer LANGUAGES CXX) include(CTest) -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) if(NOT SpWKit_CPP_WRAPPER_AVAILABLE) message(FATAL_ERROR "Installed SpWKit package does not contain the optional C++ wrapper") @@ -15,4 +15,4 @@ add_executable(spwkit_installed_cpp_consumer main.cpp) target_link_libraries(spwkit_installed_cpp_consumer PRIVATE spwkit::cpp) target_compile_features(spwkit_installed_cpp_consumer PRIVATE cxx_std_17) -add_test(NAME installed_cpp_package_consumer COMMAND spwkit_installed_cpp_consumer) \ No newline at end of file +add_test(NAME installed_cpp_package_consumer COMMAND spwkit_installed_cpp_consumer) diff --git a/examples/installed_device/CMakeLists.txt b/examples/installed_device/CMakeLists.txt index 665a54d6..2ea16cfd 100644 --- a/examples/installed_device/CMakeLists.txt +++ b/examples/installed_device/CMakeLists.txt @@ -1,7 +1,7 @@ cmake_minimum_required(VERSION 3.20) project(spwkit_installed_device_c LANGUAGES C) -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) if(NOT SpWKit_DEVICE_RUNTIME_SUPPORTED) message(FATAL_ERROR "Installed SpWKit package does not provide the Linux device runtime") @@ -18,4 +18,4 @@ target_link_libraries(spwkit_installed_device_c PRIVATE spwkit::spwkit) set_target_properties(spwkit_installed_device_c PROPERTIES C_STANDARD 11 C_STANDARD_REQUIRED YES - C_EXTENSIONS OFF) \ No newline at end of file + C_EXTENSIONS OFF) diff --git a/examples/installed_device_cpp/CMakeLists.txt b/examples/installed_device_cpp/CMakeLists.txt index dcf67f47..8e540d8b 100644 --- a/examples/installed_device_cpp/CMakeLists.txt +++ b/examples/installed_device_cpp/CMakeLists.txt @@ -1,7 +1,7 @@ cmake_minimum_required(VERSION 3.20) project(spwkit_installed_device_cpp LANGUAGES CXX) -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) if(NOT SpWKit_DEVICE_RUNTIME_SUPPORTED) message(FATAL_ERROR "Installed SpWKit package does not provide the Linux device runtime") @@ -18,4 +18,4 @@ endif() add_executable(spwkit_installed_device_cpp main.cpp) target_link_libraries(spwkit_installed_device_cpp PRIVATE spwkit::cpp) -target_compile_features(spwkit_installed_device_cpp PRIVATE cxx_std_17) \ No newline at end of file +target_compile_features(spwkit_installed_device_cpp PRIVATE cxx_std_17) diff --git a/include/spwkit/api.h b/include/spwkit/api.h index d2d1705a..ff31eb8a 100644 --- a/include/spwkit/api.h +++ b/include/spwkit/api.h @@ -9,8 +9,8 @@ extern "C" { #endif #define SPWKIT_API_VERSION_MAJOR 0u -#define SPWKIT_API_VERSION_MINOR 6u -#define SPWKIT_API_VERSION_PATCH 1u +#define SPWKIT_API_VERSION_MINOR 7u +#define SPWKIT_API_VERSION_PATCH 0u /** Result value returned by the public C API. */ typedef int32_t spw_result_t; diff --git a/integrations/ccsdspack_v2/CMakeLists.txt b/integrations/ccsdspack_v2/CMakeLists.txt index 8afe0b9c..8eb12dbb 100644 --- a/integrations/ccsdspack_v2/CMakeLists.txt +++ b/integrations/ccsdspack_v2/CMakeLists.txt @@ -1,7 +1,7 @@ cmake_minimum_required(VERSION 3.20) project(spwkit_ccsdspack_v2_integration LANGUAGES CXX) -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) find_package(CCSDSPack 2.0 CONFIG REQUIRED) if(NOT TARGET spwkit::cpp) @@ -28,4 +28,4 @@ set_target_properties(spwkit_ccsdspack_v2_peer PROPERTIES CXX_STANDARD 17 CXX_STANDARD_REQUIRED YES CXX_EXTENSIONS OFF -) \ No newline at end of file +) diff --git a/integrations/hardrt_posix/CMakeLists.txt b/integrations/hardrt_posix/CMakeLists.txt index 8b140325..95204fce 100644 --- a/integrations/hardrt_posix/CMakeLists.txt +++ b/integrations/hardrt_posix/CMakeLists.txt @@ -2,7 +2,7 @@ cmake_minimum_required(VERSION 3.20) project(spwkit_hardrt_posix_integration LANGUAGES C) find_package(HardRT 0.4 CONFIG REQUIRED) -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) if(NOT TARGET HardRT::hardrt) message(FATAL_ERROR "Installed HardRT package does not export HardRT::hardrt") @@ -17,4 +17,4 @@ set_target_properties(spwkit_hardrt_posix PROPERTIES C_STANDARD 11 C_STANDARD_REQUIRED YES C_EXTENSIONS OFF -) \ No newline at end of file +) diff --git a/integrations/hardrt_posix/README.md b/integrations/hardrt_posix/README.md index 2efcee42..baf5e64f 100644 --- a/integrations/hardrt_posix/README.md +++ b/integrations/hardrt_posix/README.md @@ -24,7 +24,7 @@ The integration consumes installed CMake packages only: ```cmake find_package(HardRT 0.4 CONFIG REQUIRED) -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) ``` Two HardRT POSIX tasks each own an independent SpWKit loopback port and validate: diff --git a/tests/d2d/README.md b/tests/d2d/README.md index 5c00e1b6..3dae358e 100644 --- a/tests/d2d/README.md +++ b/tests/d2d/README.md @@ -33,10 +33,10 @@ examples/distributed C11 public API -> spwkit::spwkit examples/distributed_cpp C++17 wrapper -> spwkit::cpp ``` -Both request the stable-compatible v0.6 package line: +Both request the stable-compatible v0.7 package line: ```cmake -find_package(SpWKit 0.6 CONFIG REQUIRED) +find_package(SpWKit 0.7 CONFIG REQUIRED) ``` The C consumer is configured with `CXX=/bin/false`. Neither application can reach source-private VSPW-TP/backend targets. @@ -71,7 +71,7 @@ The application packet is 8 KiB while the veth MTU remains 1500 bytes, so succes ## Docker Compose host topology -`compose.yml` and `run_compose.sh` add a deployment-style two-host simulation. A single container image is built from the repository, but SpWKit is first installed to `/opt/spwkit`; only then are the standalone C and C++ peers configured through `find_package(SpWKit 0.6 CONFIG REQUIRED)`. +`compose.yml` and `run_compose.sh` add a deployment-style two-host simulation. A single container image is built from the repository, but SpWKit is first installed to `/opt/spwkit`; only then are the standalone C and C++ peers configured through `find_package(SpWKit 0.7 CONFIG REQUIRED)`. Compose runs two containers on an isolated bridge network with distinct IPv4 addresses. Each container has its own process and network namespace. The same four language combinations are exercised: