# DF-5090 — ruephy(4) is dead code: unreachable latent leaf of the mii attach-panic family

File audited: `sys/dev/netif/mii_layer/ruephy.c` (284 LOC, pass 2)

## What this pack proves (statically — no guest applicable)

`ruephy_probe()` (ruephy.c:96) only accepts a miibus child whose *grandparent*
device name is exactly `"rue"` — the Realtek RTL8150 USB NIC driver. **No driver,
devclass, kernel config entry, or module named `rue` exists anywhere in this
tree.** Therefore `ruephy_attach`/`_service`/`_status`/`_reset` are unreachable
on every kernel buildable from this source, and the three latent family defects
below can never fire *today*:

1. **Empty-media attach panic** (ruephy.c:141-145) — DF-4930/DF-4957/DF-4981/
   DF-5003/DF-5053 leaf family, hub DF-5001: `no media present` branch skips
   `mii_phy_add_media()`, so `miibus_mediainit` (mii.c:228-245) calls
   `ifmedia_set()` on an empty list → `panic("ifmedia_set")`.
2. **Service-entry KASSERT** (ruephy.c:161) — DF-1973/DF-5009 family; note
   DragonFly stock `X86_64_GENERIC` *enables* INVARIANTS (config line 56), so
   this assert is live on stock kernels — held in check only by the probe gate
   and by the non-zero-instance refusal at ruephy.c:121-124.
3. **Unguarded `ifm_cur` deref** (ruephy.c:282) in the forced-media branch of
   `ruephy_status()` — shared upstream pattern; NULL only via path (1).

## Reproduce

```sh
cd /home/maxx/dfbsd/dfbsd
sh findings/poc/DF-5090/proof.sh        # exit 0 + "PROOF OK"
```

Expected: all seven invariants hold (proof.log); decisive output is section A —
the only `"rue"` string literals in the entire tree are ruephy.c's own probe
gates.

## Why no QEMU run

Phase V is exempt for Info hardening findings. Beyond the exemption, a runtime
PoC is *unconstructible*: triggering attach requires a `rue` NIC driver, which
does not exist; manufacturing a fake one on the guest would demonstrate the
already-replay-proven DF-4930 family mechanism (see the truephy/qsphy packs),
not anything new about this file. The exhaustive tree/build-system proof here
is strictly stronger than any single-guest observation.

## Fix

Retire the driver (and its `ruephyreg.h`, plus the never-compiled u4b orphans
`sys/bus/u4b/net/ruephy.c` + `ruephyreg.h`). If rue(4) is ever ported, the
DF-5001 hub guard must land with it.