VM backends (vfkit, cloudhv) lack build tags: macOS tests compile and fail on Linux (and vice versa) #107

New issue

Open

opened 2026-08-25 08:50:34 +00:00 by a73x · 0 comments

a73x commented

2026-08-25 08:50:34 +00:00

(Migrated from git.a73x.sh)

Found while verifying the volumes branch: go test ./... on Linux fails internal/agent/vfkit with listen unix .../vfkit.sock: socket: operation not permitted. vfkit is the macOS backend — it drives Apple's Virtualization.framework via a macOS-only binary — yet it has no //go:build darwin tag, so its tests compile and run on Linux where they can only fail.

Asymmetry

The wiring layer already uses build tags, but the backend packages do not:

Package	Imported only by	Build tags on source	Documented as
`internal/agent/vfkit`	`run/wire_darwin.go` (`//go:build darwin`)	none	"the macOS backend"
`internal/agent/cloudhv`	`run/wire_linux.go` (`//go:build linux`)	none	cloud-hypervisor (Linux); uses `cp --reflink`, TAP, `syscall.Setsid`

The rest of the tree already follows the convention (netenv/snoop_linux.go, hostinfo/hostinfo_{linux,darwin}.go, run/wire_{linux,darwin}.go). The two backend packages are the holdouts.

Consequence

go test ./... on Linux compiles and runs vfkit tests that can never pass (no vfkit binary, no Virtualization.framework, and this sandbox can't even bind a Unix socket — Python's socket.bind('/tmp/x.sock') fails with the same EPERM). Symmetrically, cloudhv tests run on macOS where cloud-hypervisor doesn't exist. A green suite is not a trustworthy signal until these are gated.

This is pre-existing (present on main at 8d30bd3), not introduced by the volumes branch.

The fix, roughly

Add //go:build darwin to vfkit's source + test files (except console_pty_linux_test.go, already //go:build linux), and //go:build linux to cloudhv's source + test files. Symmetric, small, matches the convention already used in netenv, hostinfo, and run/wire_*.

Why it matters before the workspace work

Building a gondolin-style workspace mount on top of volumes needs a test run that actually means something on the platform it runs on. Right now a Linux dev can't tell a real regression from a macOS-only test failing to bind a socket.

Migrated from git-collab issue fb095e7b711cfead2d844af6bb0ea48fa6d9bd08.

Original author: a73x dev@a73x.sh.

Found while verifying the `volumes` branch: `go test ./...` on Linux fails `internal/agent/vfkit` with `listen unix .../vfkit.sock: socket: operation not permitted`. vfkit is the macOS backend — it drives Apple's Virtualization.framework via a macOS-only binary — yet it has no `//go:build darwin` tag, so its tests compile and run on Linux where they can only fail. ### Asymmetry The wiring layer already uses build tags, but the backend packages do not: | Package | Imported only by | Build tags on source | Documented as | |------------------|-------------------------|----------------------|----------------------| | `internal/agent/vfkit` | `run/wire_darwin.go` (`//go:build darwin`) | none | "the macOS backend" | | `internal/agent/cloudhv` | `run/wire_linux.go` (`//go:build linux`) | none | cloud-hypervisor (Linux); uses `cp --reflink`, TAP, `syscall.Setsid` | The rest of the tree already follows the convention (`netenv/snoop_linux.go`, `hostinfo/hostinfo_{linux,darwin}.go`, `run/wire_{linux,darwin}.go`). The two backend packages are the holdouts. ### Consequence `go test ./...` on Linux compiles and runs vfkit tests that can never pass (no vfkit binary, no Virtualization.framework, and this sandbox can't even `bind` a Unix socket — Python's `socket.bind('/tmp/x.sock')` fails with the same EPERM). Symmetrically, cloudhv tests run on macOS where cloud-hypervisor doesn't exist. A green suite is not a trustworthy signal until these are gated. This is pre-existing (present on `main` at `8d30bd3`), not introduced by the `volumes` branch. ### The fix, roughly Add `//go:build darwin` to vfkit's source + test files (except `console_pty_linux_test.go`, already `//go:build linux`), and `//go:build linux` to cloudhv's source + test files. Symmetric, small, matches the convention already used in `netenv`, `hostinfo`, and `run/wire_*`. ### Why it matters before the workspace work Building a gondolin-style workspace mount on top of `volumes` needs a test run that actually means something on the platform it runs on. Right now a Linux dev can't tell a real regression from a macOS-only test failing to bind a socket. --- Migrated from git-collab issue `fb095e7b711cfead2d844af6bb0ea48fa6d9bd08`. Original author: a73x <dev@a73x.sh>.