v0.0.1 feasibility slice: workspace, config parser, §2.1 capability probes#1
Merged
lunarthegrey merged 2 commits intomainfrom Apr 20, 2026
Merged
v0.0.1 feasibility slice: workspace, config parser, §2.1 capability probes#1lunarthegrey merged 2 commits intomainfrom
lunarthegrey merged 2 commits intomainfrom
Conversation
This is the feasibility slice of the approved plan (plans/i-m-handing-you-a-stateless-simon.md). It stands up the Cargo workspace, config grammar, Module trait, and a `packetframe feasibility` subcommand that probes the host kernel for the requirements in SPEC.md §2.1 — without loading any BPF programs yet. The fast-path module ships as a stub whose lifecycle methods return NotImplemented; the real BPF program, aya loader, VLAN choreography, metrics, and circuit breaker land in v0.1. Why ship this first: it forces the crate layout, config grammar, trait shape, toolchain pins, cross-compile, CI, and release workflow into existence before any verifier work. The feasibility command is also standalone-useful — the first thing an operator runs on a new host to confirm the kernel can support PacketFrame at all. What's in the slice: - Cargo workspace: crates/common, crates/cli, crates/modules/fast-path. - Config parser (SPEC.md §6): full grammar, strict unknown-directive rejection, interface-existence check against /sys/class/net, 20 unit tests including the reference EFG config. Circuit-breaker grammar accepts `of matched` today and rejects `of rx` with an explicit future-reservation message. - Module trait (SPEC.md §3.2): shaped for the future libxdp dispatcher (priorities declared but not consulted in single-module MVP per §3.4). - Capability probes (SPEC.md §2.1) via direct bpf() syscall: kconfig flags from /proc/config.gz or /boot/config-$(uname -r), syscall reachability, XDP + sched_cls program types, all six required map types (hash, array, percpu_array, lpm_trie, devmap_hash, ringbuf), nine required helpers via minimal verifier-log probes, bpffs mount check, IPv4/IPv6 forwarding sysctls, memlock. Per-interface native-XDP trial-attach (§2.3) is reported as Deferred — it needs a real program and lands with fast-path in v0.1. - Linux-only code is cfg-gated so cargo check/test also succeeds on macOS dev laptops; non-Linux hosts receive ENOSYS-returning stubs and the report flags every BPF capability as Fail. - CLI: `feasibility` (JSON default, --human for a table) is fully implemented; `run` parses config and runs probes before stubbing module load; `detach`/`status`/`reconfigure`/`map` exit 2. Exit codes follow SPEC.md §7.3. - Fast-path stub crate claims NativeXdp at priority 1000; lifecycle returns NotImplemented except detach/sample_metrics/health_check which no-op so teardown paths are safe. - conf/example.conf matches SPEC.md §4.8 for the reference EFG. - CI: fmt, clippy -D warnings, test on ubuntu-latest plus cross-build of all four release targets via `cross`. - Release workflow: tag-triggered, four tarballs (aarch64/x86_64 × musl/gnu) with SHA256SUMS and optional GPG signature. Verified locally: - 32/32 workspace tests pass - cargo fmt --check clean - cargo clippy --all-targets --all-features -D warnings clean - Release build produces a ~1.3 MB static binary - `packetframe feasibility --human` runs end-to-end on macOS and correctly reports every BPF probe as Fail, exit code 1 Not done in this slice (per the plan's forward view): aya-ebpf toolchain setup, BPF program compilation, XDP attach/detach, VLAN push/pop/rewrite, metrics textfile, circuit breaker loop, SIGHUP reconcile, QEMU verifier CI, on-EFG acceptance archival. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`statfs.f_type` is `u32` on macOS but `i64` on glibc Linux x86_64, and `libc::syscall`'s return is `i64` on 64-bit Linux but `i32` on 32-bit. Both casts are needed on at least one target but no-ops on another, triggering `clippy::unnecessary_cast` on whichever target already has the destination type. Add targeted `#[allow]`s with the rationale inline rather than diverge the cfg branches — the casts stay because they're load-bearing on any non-default target (32-bit Linux, any musl flavor whose `f_type` happens to be `u64`). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
common,cli,modules/fast-path), the line-based config parser (SPEC.md §6), theModuletrait (§3.2), and a fully implementedpacketframe feasibilitysubcommand that probes the host kernel for every requirement in SPEC.md §2.1 via directbpf()syscalls — without loading any BPF programs.NotImplementedfrom its lifecycle methods; real BPF loading, VLAN choreography, metrics, and the circuit breaker land in v0.1 per the approved plan.-D warnings/ test / cross-build ×4 targets viacross) and a tag-triggered release workflow (musl + gnu × aarch64 + x86_64, SHA256SUMS, optional GPG signature) are in place so v0.1 arrives as a drop-in binary upgrade.Why this slice first
Rather than start on BPF code directly, v0.0.1 forces the scaffolding into existence: crate layout, config grammar, trait shape, toolchain pins, cross-compile, and release pipeline. It also gives operators the capability probe immediately — the first thing to run on a new host. Everything in v0.1 slots into this scaffolding without shape churn.
What's covered
of rxreserved-but-rejected for forward-compat, interface existence check against/sys/class/net./proc/config.gzwith/boot/config-$(uname -r)fallback),bpf()syscall reachability, XDP + sched_cls program types, all six required map types (hash, array, percpu_array, lpm_trie withBPF_F_NO_PREALLOC, devmap_hash, ringbuf sized to survive 16 KiB page hosts), nine required helpers via minimal verifier-log probes, bpffs magic check, IPv4/IPv6 forwarding sysctls,RLIMIT_MEMLOCK.cargo check/testsucceed on macOS dev laptops; non-Linux stubs returnENOSYSand the report marks every BPF capability as Fail.clap:feasibility(JSON default,--humanfor table);runparses config and runs probes before stubbing module load;detach/status/reconfigure/mapexit 2. Exit codes match SPEC.md §7.3.Reviewer notes
unknown func/unrecognized bpf_func_id/invalid funcare treated as "helper missing". EPERM and ENOSYS outcomes are surfaced as Unknown/Fail rather than smuggled into a false Pass — seeprobe_helperincrates/common/src/probe/mod.rs.Cargo.lockis committed since PacketFrame ships as a binary.SPEC.md) is deliberately not in the repo; inline code comments reference section numbers as breadcrumbs (e.g. "SPEC.md §4.2") so reviewers who have the spec can cross-check, and readers who don't still get structured pointers.rust-toolchain.toml. The split stable/nightly arrangement (SPEC.md §7.1) lands in v0.1 when the BPF crate appears undercrates/modules/fast-path/bpf/.softprops/action-gh-release@v2withgenerate_release_notes: true. GPG signing is opt-in viaPACKETFRAME_GPG_KEY/PACKETFRAME_GPG_KEY_IDsecrets — the step is skipped if either is unset, so initial releases can land before keys are provisioned.Test plan
cargo test --workspacelocally: 32 tests pass.cargo fmt --all --checkandcargo clippy --workspace --all-targets --all-features -- -D warningsclean.cargo build --releaseproduces a working binary;./packetframe --helpand./packetframe --versionreport correctly.sudo packetframe feasibility --humanreports every required capability as PASS and exits 0.packetframe feasibility --jsonoutput is archived asphase-0-feasibility-efg.jsonper SPEC.md §10.3.packetframe feasibility --config conf/example.confcleanly rejects with an interface-missing error on any host that isn't the reference EFG.net.ipv4.ip_forward=0on a test VM; the probe reports the exact sysctl to fix and exits 1.v0.0.1and confirm the release workflow publishes four tarballs withSHA256SUMS.🤖 Generated with Claude Code