sw/runtime: scaffold §14.3 canonical names + tree README #103
No reviewers
Labels
No labels
adr
agent:blocked-ci
agent:blocked-human
agent:blocked-resolver
agent:done
agent:in-progress
agent:no-touch
agent:pinged
agent:pr-open
agent:queued
agent:wip
area:board
area:funding
area:infra
area:phy
area:poplink
area:rtl
area:software
area:supply-chain
area:verification
ci-failed
ci-timeout
docs
do-not-merge
human-approved
needs-human-approval
needs-rebase
needs-triage
phase:1
ready-for-review
review:findings
review:pass
risk:tripwire
swarm:quarantined
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Fluid/fluidpop-v1!103
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "auto/issue-99-20260526T120744Z_issue99"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Adds the PLAN.md §14.3 canonical-name stub declarations to
sw/runtime/include/fluidpop.hand createssw/runtime/README.md.Context: when issue #99 was opened, the assumption was that the runtime
header did not yet exist. The runtime API design landed instead via
issue #7 / PR #16, which spells the public surface in CUDA-style
(
fluidpop_device_open,fluidpop_buf_alloc,fluidpop_memcpy_*,fluidpop_kernel_launch,fluidpop_telemetry_read). PLAN.md §14.3,however, names the canonical symbol set verbatim as
fluidpop_open,fluidpop_alloc,fluidpop_copy_h2d/_d2h/_d2d,fluidpop_launch,fluidpop_query_telemetry. Future docs(programming-model spec, ISA reference) need a stable landing path for
those exact spellings even before ADR-011 finalizes parameter shapes.
What changed
sw/runtime/include/fluidpop.h: appended a "PLAN.md §14.3 canonicalsurface (stub declarations)" block with declarations for
fluidpop_open,fluidpop_alloc,fluidpop_copy_h2d/_d2h/_d2d,fluidpop_launch,fluidpop_query_telemetry. Each prototypecarries a one-line
/* TODO: ... */comment marking what is pendingADR-011 / runtime API + driver scaffolding issue (#7). The CUDA-style
entry points and the existing
fluidpop_barrier/_broadcast/_all_gather/_all_reduce(withfluidpop_op_tSUM/MAX/MIN/AVG)sw/runtime/README.md(new): documents the tree, the four-layerstack (PLAN.md §14.1), the §14.3 → declared-symbol map, and points
at PLAN.md §14 and the runtime API + driver scaffolding issue (#7).
Acceptance criteria (from #99)
sw/runtime/include/fluidpop.hexists with declarations aboveheader-only TU; verified with
gcc -std=c11 -Wpedantic -Werrorand
g++ -std=c++17 -Wpedantic)(
FLUIDPOP_OP_SUM/_MAX/_MIN/_AVG)/* TODO: ... */describing what is still undecided
sw/runtime/README.mdcreated and references PLAN.md Section 14and the runtime API design issue (#7)
.cimplementation files created — header-only scaffoldingNotes
LICENSE.mdnot modified — theheader keeps the short
SPDX-License-Identifier: AGPL-3.0-or-laterline and points readers at the project license.
implementation backing yet; the README states this explicitly.
_POSIX_C_SOURCEmacro influidpop_mock.cisunrelated and predates this change; with the macro defined the mock
still compiles cleanly against the updated header.
Closes #99.
VERDICT: PASS
PR #103 adds the PLAN.md §14.3 canonical-name stub declarations to the existing
sw/runtime/include/fluidpop.hand creates a newsw/runtime/README.md, scoped cleanly to Issue #99. Mechanical guardrails pass: new README carriesCC-BY-SA-4.0SPDX header at line 1 (correct for doc/README), existingfluidpop.hretains itsAGPL-3.0-or-laterheader (correct for software), no AI/Anthropic attribution, no off-limits paths (onlysw/runtime/), no Chisel module so rules 4–6 don't apply. The header is verified syntactically valid C/C++ per the acceptance criteria. Rule 7 is handled carefully: each newly-added stub declaration carries an explicit/* TODO: ... */comment naming what's still pending (ADR-011 closure, driver IOCTL surface, PopLink cross-chip routing parameters), no parameter semantics are committed beyond what's syntactically necessary to declare the prototype using existing types from the prior surface (fluidpop_dev_t,fluidpop_buf_t,fluidpop_size_t, etc.), and the file-level block-comment explicitly disclaims linkage: "no implementation backs these symbols yet. Do not link against them. They are header-only scaffolding." The PR honestly addresses the situation that Issue #99 was opened under a stale assumption — the runtime header had already landed via Issue #7 / PR #16 in CUDA-style spelling — and rather than disrupting the working API surface, lands the §14.3 canonical names as stubs alongside it, with the README's "PLAN.md §14.3 → declared symbol map" table making the relationship between the two name sets explicit. The README's claims are all attributed to specific PLAN.md sections (§14.1 layer stack, §14.2 driver responsibilities, §14.3 API surface, §14.4 partitioning, §14.6 mock-driver/co-sim, §14.7 15–22 person-months estimate) and consistent with prior approved PRs in this thread on ADR-011 framing. Scope matches Issue #99 (header + README only, no .c implementation files), no drive-by edits, and the PR body honestly flags one unrelated pre-existing issue (_POSIX_C_SOURCEmacro missing influidpop_mock.c) without attempting to fix it as a drive-by.Findings
None.
CI green (head
0a957c3564), auto-approving0a957c3564fc5836c4a1CI green (head
fc5836c4a1), auto-approving