[Japabu]

Problem

netstack held every NIC driver and the stack in one process, behind Card, and each image's row named the card its machine has (devices = ["pci:02:00:00/1af4:1041"]). A driver's fault ended every connection on the machine. A driver could not start again without the stack's state. A machine nobody wrote a row for had no network: the shipped image named virtio alone, so the T14's I219 came up only in benchcase. This is stage 3 of issues/the-lan-is-not-yet-production-grade.md, which is P4 of issues/there-is-no-wifi.md. W5 needs its match table.

What changes

• toyos-link (lib/link) is the protocol between netstack and each NIC driver. It is built on toyos::transport and adds no transport primitive.
  • Opening. A driver connects to netstack's link port and sends a region it made with its hello (MAC address and name). netstack answers OPENED or REFUSED. After that the connection carries only doorbell bytes, and its hang-up ends the link. This is blockring's shape.
  • Region header. One ring of frame lengths each way. The driver states its link (down, up with speed and duplex, or unreported) and answers counters. The stack writes the multicast groups it joined and asks for counters.
  • Slots. Frame n is in slot n of its ring, so a slot is its producer's again exactly when the consumer releases its entry. There are no return queues. Each side copies a frame once (the model S2 measures).
  • Wakes. A doorbell follows a publish. A full ring's producer sets a want, and the consumer takes it when it releases. Each side does this with one AcqRel swap of the want's word, so whichever swap comes second in that word's order sees the other. tests/ends_loom.rs checks this under loom, and a gate control reds it with the swaps Relaxed.
  • Bounds. Everything the peer writes is bounded before it is believed: cursors by the transport, lengths by the slot, the link word by Link::decode, and groups by count and encoding. A fault ends the link by name. Counter values are displayed in inspect and never acted on, so no arithmetic touches them. That was the orchestrator's condition for putting counters in the region.
• The drivers are programs of their own.
  • system/i219 drives the I219 and the 82574, with toyos-i219 moved under it unchanged but for comments.
  • system/virtio-net is the former netstack/src/virtio_net.rs, without its RefCells.
  • Each is a drives row. The supervisor's existing match table binds one process per function by class, vendor and device, so the supervisor itself is unchanged.
  • virtio's row has restart = true: the supervisor starts it again when it ends other than by exit 0.
  • The I219's row does not restart, by the orchestrator's decision. Its start resets the part, and issues/no-machine-has-read-an-intel-nic-across-a-link-change.md records a reset over a ring left by a link change as not known to be safe, with a T14 hang on record. That issue's rule now names the I219 row.
  • Both run toyos_link::driver::drive: one pass per wake, at most a ring of frames each way. When netstack hangs up, the driver connects again with a fresh region and its device stays up.
• netstack is the stack alone. It claims no device, and Card, card.rs and CARDS are gone.
  • The hello carries toyos-link's own checked Address, an individual one. A group's address, or a name that is not ASCII letters, digits and -, is refused Malformed at decode.
  • netstack builds its IndividualMac from that address once, as it hears the hello, and refuses Malformed should the conversion ever fail. No driver's hello reaches a panic in netstack, and the drivers do not depend on netstack's wire crate.
  • The node is made with the first driver's address. Until P5 runs several links, a hello with another address is refused OneLink by name. So is a hello with the node's address while that link is still alive, which netstack reads on the connection at that moment. The kernel closes a dead driver's handles before its end is published, so a restarted driver's hello always finds the old link already hung up.
  • A link whose driver wrote what no driver writes ends, and that address's next hello is refused Faulted. The driver ends on that refusal, so the supervisor's restart budget (3 in 10 s, then given up by name) bounds a driver that keeps doing it.
  • A link that ends leaves every connection to the node. The node hears down, and up again on the restarted driver's hello.
  • inspect asks the driver for its counters and answers once it has them, or after 1 s without them.
• Manifests. images/system.toml declares both drivers, so the shipped image now drives the T14's I219 with no row naming the T14. netcase declares both drivers, benchcase the I219, and metalcase virtio. The new linkcase declares none, so its job runs the driver itself.
• Issues.
  • netstack-ends-for-the-boot-on-a-nic-it-cannot-drive-on is closed: its exit is the restart test below.
  • P4 in the Wi-Fi track, stage 3 of the LAN track, and netstack-drives-one-card say what is built and what is owed.
  • Paths are moved in the issues that cited the old files.

Decisions

• The node needs a MAC, so netstack waits for its first link. Building the node before any link means one interface per link, each with its own DHCP client and MAC. That is P5's design (issues/netstack-drives-one-card.md), and pre-empting it here would be redone. So netstack serves nothing until the first hello, and leaves after LINK_BOUND (30 s) on a machine where no driver says hello.
  • Temporary gap: on a NIC-less boot, clients wait up to 30 s before they hear netstack gone, where before they heard it at once.
  • Recorded: in issues/netstack-drives-one-card.md, with "a node that serves before any link, so LINK_BOUND goes" added to P5's exit.
  • Rejected alternative: the supervisor passing netstack --drivers <n>, as it does for the block service. It would have removed the delay, but it couples the supervisor to netstack, P5 deletes it, and no guest job could then start the driver itself for the restart test.
• No MTU or offload in the hello. The stack sends at most 1,514-byte frames (asserted at compile time to fit a 2,048-byte slot), and no driver offers an offload. A field nobody reads would be speculative.
• Doorbells as blockring has them today, as the orchestrator directed. When the IPC migration's events land, link changes along with blockring, with no bridge.

Checks

All runs are on macOS (arm64 host), QEMU x86-64. Every log, its command, revision and exit code is indexed in README.

Check	Revision	Exit	Log
cargo run -- --ci host, 107 steps, including toyos-link's host tests and the new loom control	8bdf491 (this head)	0	ci-host-3
cargo test --test toyos-build -- netstack_holders_exported_to_children a_link_ends_under_a_held_stream_and_comes_back udp_receive_times_out a_virtio_function_without_access_platform_is_refused iommu_virtio_platform	98c23c396	0	guest-4
loom: cargo test -p toyos-link --test ends_loom	the want as two AcqRel swaps	0	loom-1
loom control: --features mutate-want-relaxed, which reds with loom's deadlock (a lost wake)	the same	101	loom-control-1
negative control: the restart test with netstack panicking when its link ends (patch)	1c610d4c7 + patch	1	control-1
T14, one benchcase boot run by the orchestrator (rc=0; Linux found the I219 afterwards), judged with the same --metal-readback command: i219_carries_netstacks_link and i219_leaves_ulp_unarmed passed, the I219 up at 1000 Mb/s full duplex 2,658 ms after its driver came up	8bdf491	0	judge, request

• Why the guest run at 98c23c396 still stands. 8bdf491 differs from it only in lib/link/tests/ends_loom.rs (&*page to &page, a clippy finding), which no image contains.
• Earlier reds, each one this change's. The first guest run (guest-1) was red three times:
  1. linkcase did not ship /system/bin/virtio-net.
  2. iommu_virtio_platform's no-unit arm stopped waiting before the supervisor refused the driver row, which the supervisor now starts last.
  3. The untranslated arm read netstack's 30 s wait as a stall.
• The restart test's FIN. The next run (guest-2) had the restart job pass, but the harness never saw the FIN. The job killed its driver right after dropping the stream, and a FIN queued with no link never leaves. The job now shuts down its write side and reads the harness's FIN before it ends its driver.
• The interrupted host run. ci-host-2 aborted when the host's disk filled, and the clippy findings it reached first are fixed.
• The negative control. It reds by name: "the log did not show the link's end and a link opened after it", because netstack died with its link and the restarted driver found its port closed.

Round 2: the review's six blockers

Check	Revision	Exit	Log
the five network guest tests	b5f9cc0	0	guest-r1
cargo run -- --ci host, 107 steps	b5f9cc0	0	ci-host-r1

• New host tests: a group's address and a bad name in the hello are refused.
• What round 2 changed.
  • netstack's hello handling: an address check and Faulted, OneLink only for another address or a live link, and pending links let go after the handshake bound, the first wait included.
  • Its counter asks: counters are read only for an ask, and a link opened while an inspect waits is asked.
  • The I219 driver's own change: the hello's address and name checks.
  • restart removed from the I219 rows.
• The T14 rows (8bdf491) predate rounds 2 and 3. None of these changes is specific to the T14. The 82574 link on QEMU's e1000e runs the same i219 binary and the same netstack code, and it passed at b5f9cc0 and again at 4864cf7. The T14's individual address and the name i219 pass the hello's checks. Removing restart changes nothing on a boot that passes.
• Not run: the T14 rows have not been run again.
• 559a69d changes only the S2 record.

Round 3: the link's address is its own type

The round-2 review's one blocker was that toyos-link depended on system/netstack/wire for one six-byte type. That pulled Ethernet, IPv4 and TCP wire formats and toyos-crypto into both drivers. lib/link now has its own checked Address, and cargo tree -p i219 no longer names toyos-net-wire or toyos-crypto.

Check	Revision	Exit	Log
the five network guest tests	4864cf7	0	guest-r2
cargo test -p toyos-link (wire tests of the address and name)	4864cf7	0	—

Round 4: the link's loom control reaches its verdict on Linux

The merge queue dropped the PR: mutate-want-relaxed printed no FAILED line on the Linux runner (run 40782639843). The model put its 768-word page of loom atomics on loom's 32 KiB coroutine stack. Unwinding the deadlock overflowed that stack and aborted the test binary. With the page on the heap, a second abort followed: loom's Arc panics in its drop while a failed model unwinds (issues/loom-arc-panics-in-its-drop-while-a-failed-model-unwinds.md). The model now shares one Rc, as transport_loom does, and collects its page on the heap. Each fix alone still aborts; the probes are logged. The issue's exit now names this model too.

• cargo run -- --ci host at 6807935 on origin/main 0c7e62c: exit 0, 107 steps, control mutate-want-relaxed: 1 verdict(s) reached.
• Evidence: https://github.com/ToyOSOrg/evidence/blob/c5f4360a5216691f30c0513ba5d05b6fbd256f4b/p4-r4/README.md
• The guest and T14 results above still apply: the change is one host test file and an issue record, which no image holds.

Integration tests and where they run

Test	Runs on	Why it needs the guest
a_link_ends_under_a_held_stream_and_comes_back (new)	QEMU x86-64	netstack's node surviving a link's end, a driver's hello on a new region, and the claim given back and minted again cross three processes and a device.
netstack_holders_exported_to_children, now also over QEMU's e1000e (new HeadlessE1000e profile)	QEMU x86-64	Covers the NIC no row names a machine for.
i219_carries_netstacks_link (new metal row)	the T14	Rides i219_leaves_ulp_unarmed's boot. Its new job lan_lease waits on the served log for netstack's lease, then the judge reads that the link opened, came up and carried a lease, and never ended.

benchcase now serves log to its runner.

Owed

• T14 boot. Done: both rows passed (above).

• AMD bench. No row: the AMD bench has no wired NIC ToyOS drives.

• S2: done. It is a scout and never lands. On the T14 (TSC 2.42 GHz), 2^18 frames of 1,514 bytes crossed the link between two processes, each side copying each frame once (S2, judge).

  Batch per doorbell	One-CPU cycles/frame, rx / tx	Frames/s of one CPU	Frames/s observed on two CPUs, rx / tx
  1	3,273 / 3,080	about 740,000 / 785,000	1,364,291 / 1,454,730
  8	921 / 919	about 2.6 million	5,275,530 / 5,277,554
  32	623 / 611	about 3.9 million	7,795,948 / 7,941,636

  • Measures. One-CPU cycles per frame is both processes' kernel-counted CPU time per frame. Each process was busy for about the whole run, so the observed rates ran on two CPUs, since ToyOS has no CPU pinning.
  • Against full rate. Full rate needs 200,163 frames a second each way, about 400,000 together. With a doorbell per frame that is about 54% of one CPU; at batches of 8 and 32 it is about 15% and 10%.
  • Status. Reported; it decides nothing by itself.

Risks

• The restart claim is shown in two parts. a_link_ends_under_a_held_stream_and_comes_back kills a driver its job started and starts another, and the stream survives. The supervisor's own restart of a drives row is held by the lifecycle crate's host tests. No single test shows the supervisor restarting a NIC driver under a held stream.
• Read on metal once. The I219's path through a link has one T14 boot behind it: the link up, a lease, nothing ended. No load or link change has crossed it there yet; those are stage 2's rows.
• Line names changed. The drivers' lines now start i219:, 82574: and virtio-net:. Updated: the iommu judges, the I219 judge, and the issues that quote a line.

🤖 Generated with Claude Code

[Japabu]

Review of #1106 at 4105fe8 (P4 / LAN stage 3), round 1

Architecture

The shape is right. The protocol lives in its own library (lib/link), with its own wire types and errors (Fault, Refusal). toyos-abi appears only where a kernel call's SyscallError is matched. The two drivers become drives rows that the existing match table binds, so the supervisor needs no change. netstack loses every device dependency. Card, card.rs, CARDS and netstack's devices rows are gone: a tree-wide grep finds them only in a historical table in issues/clippy-stage-two-is-lints-one-at-a-time.md. The shared driver::drive loop has two real users.

I checked the full-ring handshake. Each side does one AcqRel swap of the want's word, and the swaps are totally ordered on that word. If the consumer's swap comes second, it reads 1 and rings. If the producer's comes second, it acquires the consumer's release, which follows the head store, so its space() sees the room. The loom model exercises the transmit direction, and receive uses the same want/wanted functions. Frames published before OPENED are read on the stack's first pass, and Session.ring starts true.

Every ring index, length, link word, group count and group encoding is bounded before it is used. Counters are display-only. The stack's push never re-reads the head within the room it was given, so a driver moving TX_HEAD cannot trip send's assertion.

Size: production is about +1.9k/−0.5k lines. lib/link is about 1.1k of that, including its in-file tests, and netstack grows by about 110 lines net. Tests are about +600/−50, issues +59/−77.

Findings

BLOCKER 1. A driver's hello can panic netstack.

• Where: system/netstack/src/main.rs:420 (IndividualMac::new(..).unwrap_or_else(panic)) together with lib/link/src/wire.rs:41-47.
• Problem: Hello::decode accepts any six bytes. A hello whose address has the group bit set (from a buggy driver, or a virtio device configured with such a MAC) panics netstack in main. netstack has no restart, so the machine loses its network for the boot and every client hears Gone. The brief's condition was that a bad driver never crashes netstack.
• Fix: validate once at the boundary. Hello should carry an address already known to be individual, and a group address should be refused Malformed (add a case to a_hello_no_driver_writes_is_refused). netstack should then build its IndividualMac from that validated value without a panic arm.

BLOCKER 2. restart = true on the I219 rows re-enables a reset the records say is not known to be safe.

• Where: images/system.toml and tests/images/benchcase.toml:47.
• Problem: issues/no-machine-has-read-an-intel-nic-across-a-link-change.md:71-75 says: "The refusal is safe only while netstack's row has no restart … With a restart the refusal becomes an automatic open over the ring the part kept, which is the reset this issue does not know to be safe." Lines 97-99 repeat it ("Until that is read, netstack's row takes no restart"). The issue also cites the-t14-hung-after-rebooting-with-its-i219-faulted.md.
• Consequence: i219/src/nic.rs:255-260 panics on exactly that refusal (stranded descriptors past the deadline). The supervisor now restarts the driver, and open resets the part over the live ring, with a T14 hang as the recorded risk. The PR changed this file's paths but not its rule, and its text still says "netstack" throughout (lines 15, 44-45, 71-73, 90-99).
• Fix: either drop restart from the I219 rows until stage 2's row reads that reset (virtio already carries the stage's restart exit), or bring evidence and the owner's decision and rewrite the issue to match. Do not leave the two contradicting each other.

BLOCKER 3. The fault loop has no bound (risk a). Bound it now.

• Where: system/netstack/src/main.rs:491-502 and lib/link/src/driver.rs:103.
• Problem: a link ended for a Fault drops the connection. The same driver process reconnects at once with a fresh 2 MiB region, netstack opens it again, and the cycle repeats. Each round writes at least four log lines (two from netstack, two from the driver) and allocates and frees a region, at CPU speed, for as long as the bug persists. The persistent log file and one CPU take the cost.
• Why it matters: the supervisor already has the bound, RESTARTS = 3 within WINDOW = 10 s and then GiveUp by name (system/supervisor/lifecycle/src/restart.rs, applied to drives rows in drives.rs). An in-process reconnect never reaches that budget. Nothing in issues/ records the loop either, so it is unrecorded debt as well as unbounded.
• Cheapest fix I see: route a fault to the driver's death. For example, netstack refuses the faulted address's next hello once with a new Refusal, the driver panics on that refusal, and the supervisor's budget bounds the cycle and names its end. Any equivalent that ends in the existing budget is fine.

BLOCKER 4. A restarted driver can be refused for good.

• Where: system/netstack/src/main.rs:330-351 (hear_links).
• Problem: the old link's hang-up is noticed only in Session::receive, at the top of a pass. hear_links runs after the wait. Suppose the old driver dies and its replacement's hello is readable before netstack's next pass top, for example while netstack is busy in a long pass. Then link.is_some() refuses the replacement OneLink, drive returns, the process exits 0, and restart::owed gives no restart. The network is gone for the boot.
• The window is narrow, because it needs a supervisor restart and a device bring-up inside one netstack pass. But the outcome is permanent, and it sits in the exact path this stage delivers.
• Fix: refuse OneLink only for a different address. Leave a same-address hello pending while a link is held (HANDSHAKE_TIMEOUT already bounds it), or check the held session's connection for a hang-up before refusing.

BLOCKER 5. False or stale comments.

• images/system.toml:136: "The supervisor starts the NIC drivers before it and tells it how many." Both halves are false. That is the rejected --drivers <n> alternative, and the supervisor starts drives rows after the services (the PR's own iommu.rs comment says so).
• tests/images/netcase.toml:5-8: the same false claim ("starts the NIC drivers before netstack and says how many"). It also implies netstack leaves at once, when it leaves after LINK_BOUND.
• lib/link/src/layout.rs:8: "the one size shared memory comes in" is false, because SharedMemory::create takes any length. 2 MiB is transport::Geometry::BYTES. Say that or say nothing.
• lib/link/src/driver.rs:11-13: "the port queues the connection for the stack started in its place". netstack has no restart. The hang-up a running netstack actually makes is a fault, after which the same stack opens again. The comment describes the rare case (swap) as the rule.

BLOCKER 6. Issue records this change makes inaccurate.

• issues/netstack-is-never-told-the-machine-stops.md:7-12 still says netstack "holds its card through devices". The process that is never told of the stop is now the i219 drives row, and the subject and exit should say so.
• issues/the-intel-nics-room-and-wake-are-unread-on-hardware.md:9-13: "netstack offers its card a frame … it sleeps on the claim". Since this change, the driver does that over the link.
• I am raising only records whose subject this change moved, not the tracker in general.

SUGGESTION 1. Silent pending links in first_link. first_link (main.rs:363-382) has no HANDSHAKE_TIMEOUT retain for pending links, unlike the main loop (:561). Two silent connections can hold both MAX_PENDING_LINKS slots for the whole 30 s. Only drivers the manifest grants link can connect, so the risk is low.

SUGGESTION 2. The hello's label. It is any UTF-8 string up to 32 bytes, newlines included, and it is printed into the netstack lines that judges match (netstack: i219's link is open). A short ASCII name check in Hello::decode costs nothing.

SUGGESTION 3. Stale counters on a reopened link. On a new Session, Stack::asked == COUNTERS_ANSWERED == 0. An inspect still pending across a reopen is therefore answered at once with empty counters. This is display-only, but gating Session::counters on self.asked makes it exact.

SUGGESTION 4. The stop pipe. Now that the I219 driver is a drives row, the supervisor's existing DRIVER_STOP pipe (is_disk_driver at system/supervisor/src/main.rs:1215) is close to being the exit for netstack-is-never-told-the-machine-stops. That belongs to a follow-up, not this PR.

Risk (b): the 30 s wait on a machine with no NIC

This is acceptable as a recorded temporary gap. It is in issues/netstack-drives-one-card.md, with "LINK_BOUND goes" in P5's exit, and the alternative the PR rejected would have coupled the supervisor to netstack only for P5 to delete it. One thing to know: benchcase boots on the AMD bench now keep netstack for 30 s before the osbench network groups hear it is gone. No AMD run checked this. It fits inside the row's 60 s margin by inspection, not by measurement.

Evidence

• Verified: the guest run at 98c23c396 differs from 8bdf491 only in lib/link/tests/ends_loom.rs, and 8bdf491 differs from 4105fe8 only in issues/there-is-no-wifi.md. The reuse holds.
• Verified: guest-4 passes all five network tests (exit 0). The T14 judge passes both rows at 8bdf491 (exit 0). The loom control is registered in build/ci.rs CONTROLS and ran inside ci-host-3.
• Gap: the restart test kills and restarts a driver that the job itself started. The supervisor's own restart of a drives row is held only by the lifecycle host tests. So "killing a driver restarts it with connections intact" is shown by composing the two, not by one test. That is acceptable, but the PR and records should not imply a single test shows it.
• Not run: the_kernel_tells_a_bypassing_console_physical_addresses, which also boots netcase. Only boot completion is judged, so the risk is low.
• Each fix above is cheap to hold: a wire.rs unit test for blocker 1, and inspection plus the existing restart test for blocker 4. The restart decision in blocker 2 is a record and design matter, not a measurement.

SEND BACK

[Japabu]

Round 1 answered at b5f9cc0 (records in 559a69d)

1. Hello address. Hello carries an IndividualMac. Hello::decode refuses a group's address, the broadcast address, and an empty or non-[A-Za-z0-9-] name, each Malformed. The cases are in a_hello_no_driver_writes_is_refused, and netstack has no panic arm left for the address. A driver whose device reports a group's address ends itself by name.
2. I219 restart. The I219 rows (system, netcase, benchcase) have no restart, and the images say why. no-machine-has-read-an-intel-nic-across-a-link-change.md now states its rule of the i219 row, and its text names the driver.
3. Fault loop. A Fault sets faulted. That address's next hello is refused Faulted, the driver panics on it, and the supervisor's budget (3 in 10 s) bounds the cycle. A non-restarting row ends there. This is recorded in driver.rs's header, wire::Refusal::Faulted and P4's entry in issues/there-is-no-wifi.md.
4. Restarted driver. OneLink is refused only for another address, or for the node's address while the held link is alive. That is read with Session::alive when the hello arrives, and the old link is ended first if it has hung up.
5. Comments. The four are corrected: images/system.toml, netcase.toml, layout.rs and driver.rs.
6. Issue records. the-intel-nics-room-and-wake-are-unread-on-hardware.md names the driver. The stop record is renamed the-i219-driver-is-never-told-the-machine-stops.md, because its subject moved.

Suggestions taken:

• 1: first_link lets a pending connection go after HANDSHAKE_TIMEOUT, inside hear_links.
• 2: the label check.
• 3: counters are read only for an ask, and a link opened while an inspect waits is asked.

Not taken: 4, the stop pipe, which belongs to the renamed record's follow-up.

Evidence gap: the PR now states that the restart claim is shown by two tests composed, not by one.

Checks at b5f9cc0: the five network guest tests and --ci host both exit 0 (links in the body). The T14 rows predate this round; see the body for why I hold their reading still applies.

[Japabu]

Review of #1106, round 2, at 559a69d (fixes in b5f9cc0)

I reviewed only what round 2 changed. Everything settled in round 1 stays settled.

The round 1 blockers

1. Hello address: resolved, but the fix adds a new blocker (below). Hello::decode refuses group and broadcast addresses, and wire.rs's tests cover both. netstack's panic arm for the address is gone. A driver whose device reports a group address now ends by name.
2. I219 restart: resolved. restart is gone from the I219 rows in system.toml, netcase and benchcase. The images say why. no-machine-has-read-an-intel-nic-across-a-link-change.md now states its rule in terms of the i219 row, and its text names the driver throughout. P4's entry in there-is-no-wifi.md says the I219 does not restart, so the stage's restart exit holds for virtio alone. That is now stated honestly.
3. Fault loop: resolved. I traced the cycle:
   • A Fault ends the link and sets faulted.
   • The same process reconnects at once. Its hello, with the node's address, takes the flag and is refused Faulted.
   • drive panics on Faulted (driver.rs:105), and the supervisor's drives budget (3 restarts in 10 s, then GiveUp) applies.
   • A restarted virtio driver's next hello finds the flag clear and opens.
   • So every cycle costs one supervisor restart, and the loop ends by name within the budget. The I219, which has no restart, ends at the first Faulted.
   • A hello with another address is refused OneLink before the flag is read, so it cannot consume the flag.
4. Restarted driver: resolved. A same-address hello while a link is held now calls Session::alive. If the old connection has hung up, the link is ended and the hello is opened. The ordering claim in the comment at main.rs:579-582 checks out: teardown_resources runs ops::close_all(&mut data.handles) (kernel/src/process.rs:769) before publish_climb publishes the exit. The supervisor only restarts after that publication, so a restarted driver's hello always finds the old connection's end readable.
5. Comments: resolved. The four corrected comments are accurate.
6. Issue records: resolved. The stop record was renamed, and no reference to the old name remains in the tree. the-intel-nics-room-and-wake-are-unread-on-hardware.md names the driver, and its exit was restated.

The suggestions taken

• First-link timeout: sound. hear_links lets a silent pending link go after HANDSHAKE_TIMEOUT, at both call sites. first_link's wait is not shortened to that timeout, so a silent connection is let go only on the next wake. A driver refused while both slots are full sees the hang-up, reconnects, and so wakes the loop itself. This is fine.
• Name check: sound. Letters, digits and -, with a length of 1 to 32. The three real names, i219, 82574 and virtio-net, pass, and the new tests cover the rejected forms.
• Counters: sound. Session::counters answers only after an ask, and a link opened while an inspect waits is asked (ask_counters is idempotent). The ask's doorbell goes out in the same pass through ring().

New finding

BLOCKER: toyos-link now depends on netstack's internal wire crate.

• Where: lib/link/Cargo.toml:25, toyos-net-wire = { path = "../../system/netstack/wire" }.
• Problem: both driver programs now build and link toyos-net-wire: about 2.8k lines of Ethernet, IPv4 and TCP wire formats, and through it toyos-crypto. They need it for one six-byte newtype. Under issues/the-tree-says-who-uses-each-thing.md's rule, toyos-net-wire now has users outside netstack and so belongs under lib/. That issue lists the tree's departures from the rule, and this one is not among them. The fix creates both an unrecorded departure and a driver-to-stack coupling that the link boundary exists to avoid.
• Cheapest fix: toyos-link keeps its own validated address type, a [u8; 6] whose group bit is checked in Hello::decode, and the drivers check their device's address against that same type. netstack builds its IndividualMac from it in Pending::hear and refuses Malformed if that ever fails, so no panic arm comes back.
• Alternatives: move toyos-net-wire to lib/, or record the departure in that issue with its exit. I would choose the first.

The T14 rows not rerun

The reasoning is sufficient, though the PR body describes the change too narrowly.

• The body says round 2 "changes on that path only the hello's check". Round 2 also restructured netstack's first-link and hello handling, the counters ask, and the removed restart.
• None of that is specific to the T14. The 82574 link on QEMU's e1000e runs the same i219 binary and the same netstack code, and it passed netstack_holders_exported_to_children at b5f9cc0 (guest-r1, exit 0).
• The I219 driver's own code changed only in the hello's address and name checks, which the T14's individual address and the name i219 pass. Dropping restart changes nothing on a boot that passes.
• So the T14 judges, which read the driver's ULP lines, link is open, link up, the lease and no link ended, rest on paths that are either unchanged or exercised in the guest.
• One caveat: the fix for the blocker above touches the hello on both sides. That change is of the same kind and is held by the same e1000e and virtio guest runs plus the wire.rs tests. I see no need for a T14 rerun after it, provided the guest network tests are run again.

Evidence

• guest-r1: five network tests at b5f9cc0, exit 0.
• ci-host-r1: 107 steps at b5f9cc0, exit 0.
• 559a69d differs from b5f9cc0 only in issues/there-is-no-wifi.md (the S2 record).
• The Faulted and alive paths are held by inspection, as traced above. That is enough for their size.

SEND BACK for the one new blocker. Everything else is resolved.

[Japabu]

Orchestrator: r2's one blocker checked against 559a69d..4864cf7. toyos-link has its own checked individual Address with no netstack/wire dependency, and netstack converts it to IndividualMac once at the hello, refusing Malformed on failure. The five network guest tests pass at the head, and the PR body covers round 2's netstack changes. The T14 rows at 8bdf491 stand for the reason r2 accepted. Landing.

[Japabu]

Orchestrator: re-queueing. The merge queue's red was the link loom control's test aborting (stack overflow, then loom's Arc drop panic during unwind) before it printed its verdict. 6807935 shares the page by Rc and builds it on the heap, as transport_loom does. Host CI is green with mutate-want-relaxed: 1 verdict(s) reached. Evidence: https://github.com/ToyOSOrg/evidence/blob/c5f4360a5216691f30c0513ba5d05b6fbd256f4b/p4-r4/README.md. The change is test-only, and the rebase onto 0c7e62c touches no link or netstack code.