Skip to content

DaynaPort SCSI/Link target (--features daynaport) - #81

Merged
techomancer merged 1 commit into
techomancer:mainfrom
danifunker:add-daynaport
Aug 13, 2026
Merged

DaynaPort SCSI/Link target (--features daynaport)#81
techomancer merged 1 commit into
techomancer:mainfrom
danifunker:add-daynaport

Conversation

@danifunker

Copy link
Copy Markdown
Contributor

Ethernet over the SCSI bus: a type-3 Processor target selectable per SCSI id, giving the guest a second network path independent of the onboard SEEQ. Off by default — it is only useful with a guest driver (IRIX: irixdayna -> dp0).

src/daynaport.rs owns two rtrb rings and hands the far ends to its own NatEngine (or PcapEngine) on a daynaN-nat thread, exactly as seeq8003 does; the front end is the five vendor 6-byte CDBs instead of DMA descriptor rings.

0x08/0x0A collide with READ(6)/WRITE(6), which needs handling in two places: ScsiDevice now carries a DeviceKind and dispatches DaynaPort ahead of the storage match, and the WD33C93A sizes a DaynaPort WRITE(6) data-out phase from the byte count in CDB 3..4 rather than blocks x 512.

Each target runs its own NAT gateway on its own subnet (default 192.168.10.0/24), inheriting NAT-vs-PCAP mode and the NFS export but not host port forwards. Config: kind = "daynaport" in [scsi.N] with optional mac / subnet; cdrom = true keeps working unchanged. Monitor: scsi dayna. GUI: target type dropdown on the Disks tab with MAC and subnet fields.

Verified: 21 unit tests over the record format, filtering and dispatch precedence; the PROM bus scan finds the target (hinv -v -> SCSI Device: Controller 0 ID 3), so INQUIRY works over real DMA. The rest of the acceptance ladder (ARP/ping/TCP) needs the guest driver and is not yet run.

Ethernet over the SCSI bus: a type-3 Processor target selectable per SCSI id,
giving the guest a second network path independent of the onboard SEEQ. Off by
default — it is only useful with a guest driver (IRIX: irixdayna -> dp0).

src/daynaport.rs owns two rtrb rings and hands the far ends to its own
NatEngine (or PcapEngine) on a daynaN-nat thread, exactly as seeq8003 does;
the front end is the five vendor 6-byte CDBs instead of DMA descriptor rings.

0x08/0x0A collide with READ(6)/WRITE(6), which needs handling in two places:
ScsiDevice now carries a DeviceKind and dispatches DaynaPort ahead of the
storage match, and the WD33C93A sizes a DaynaPort WRITE(6) data-out phase from
the byte count in CDB 3..4 rather than blocks x 512.

Each target runs its own NAT gateway on its own subnet (default
192.168.10.0/24), inheriting NAT-vs-PCAP mode and the NFS export but not host
port forwards. Config: kind = "daynaport" in [scsi.N] with optional mac /
subnet; cdrom = true keeps working unchanged. Monitor: scsi dayna. GUI: target
type dropdown on the Disks tab with MAC and subnet fields.

Verified: 21 unit tests over the record format, filtering and dispatch
precedence; the PROM bus scan finds the target (hinv -v -> SCSI Device:
Controller 0 ID 3), so INQUIRY works over real DMA. The rest of the acceptance
ladder (ARP/ping/TCP) needs the guest driver and is not yet run.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@techomancer
techomancer merged commit 734660b into techomancer:main Aug 13, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants