Skip to content

Investigate bsdsocket.library support via host-socket passthrough #33

Description

@sidick

Summary

Look into implementing bsdsocket.library (the standard AmigaOS TCP/IP stack API, as popularized by AmiTCP/Genesis/Roadshow/Miami) using a host-socket passthrough design, rather than emulating a real guest-side TCP/IP stack (ARP/IP/TCP state machines, retransmission, etc.).

A real, working precedent: Copperline's hostsocket-plugin

Copperline (the cycle-exact Amiga emulator this project already uses for ground-truth testing) has a real, conformance-tested bsdsocket.library implementation at crates/hostsocket-plugin in its own repo, and it already offers exactly this as a second transport option alongside its default embedded smoltcp TCP/IP stack:

  • Default transport (net = "loopback"/"nat"/"bridge"): a full embedded smoltcp IP stack running inside the plugin, chosen because Copperline needs cycle-exact, byte-for-byte-deterministic emulation -- a real host socket's timing isn't reproducible, so the guest-visible network stack has to be simulated in full.
  • Host-socket backend ([config] transport = "host"): bypasses smoltcp entirely and proxies TCP/UDP socket calls straight onto real host OS sockets via a small, explicit set of host imports: sock_open/connect/send/recv/poll/close/bind/listen/accept/local_addr/peer_addr/sendto/recvfrom/setopt/getopt/dup/shutdown/peek/nread/send_oob/recv_oob. This is the "Amiberry-style" option the plugin's own doc comments name it after -- i.e. the same non-deterministic-but-simple passthrough approach other emulators use.

volamos doesn't have Copperline's determinism constraint (it's not trying to be cycle-exact or reproducible in that sense), so the host-socket backend -- not the embedded-stack default -- is the directly applicable model: implement bsdsocket.library's LVOs by translating each call onto Rust's std::net/mio, the same shape as Copperline's sock_* host-import boundary, without ever needing an embedded TCP/IP stack at all.

Concretely worth reading before starting:

  • crates/hostsocket-plugin/src/lib.rs's HostFdSlot/Board::host_backend section (search // -- Host-socket backend) -- the design rationale for keeping this a small, separate code path rather than folding it into the smoltcp-backed fd table: "every unimplemented call ... is simply absent from fds, so fd_index reports it as no-such-descriptor (ENOTSOCK/EBADF) exactly like any other invalid fd, with no risk to the existing [default] path at all." Same incremental, low-risk shape volamos's own library-gap work already follows (implement what's needed, fail cleanly/honestly on what isn't).
  • crates/hostsocket-plugin/docs/bsdsocktest-status.md -- a real conformance record against the external bsdsocktest suite. The host backend passes 126/142 (loopback tier); the remaining gaps are documented and instructive for scoping a first volamos pass: shutdown(), MSG_PEEK, sendmsg/recvmsg, FIONREAD, SO_EVENTMASK/GetSocketEvents, and a partial MSG_OOB (out-of-band) gap. Worth pulling this same test suite into volamos's own test flow once there's something to test.

Open questions to research before implementing

  • Which bsdsocket.library version/API surface to target (original AmiTCP 4.x bsdsocket.library LVOs vs. later Roadshow extensions) -- check the NDK/FD files for the LVO table and exact register conventions (the ndk32-autodocs skill, or amitools' fd/ directory).
  • How guest struct sockaddr_in/hostent/etc. layouts (big-endian, Amiga struct packing) map onto host equivalents -- probably a straightforward byte-order/field-order translation layer, similar to how dosfile.rs already translates AmigaDOS structures to host I/O. Copperline's sock_* ABI already made these decisions (e.g. ip/port as plain i32s at the host-import boundary) and is a ready reference.
  • Blocking semantics: real bsdsocket.library calls can block the calling task; volamos is currently single-tasking/synchronous (per crate::exectask's scope). Copperline's Phase 2 replaced an initial guest-side busy-spin with real Wait/Signal-based blocking via a guest-installed interrupt server -- worth understanding before deciding volamos's own approach (a plain blocking host call may be simpler and sufficient for a single-tasked guest).
  • WaitSelect/select() multiplexing across multiple sockets and/or Exec signals.
  • Any corpus binary that would actually exercise this (AmiTCP-era CLI tools, an FTP/telnet client, etc.) to validate against, similar to how other library work in this project has been grounded against real Aminet binaries rather than guesswork.
  • Sandboxing/security implications of giving guest code real host network access -- worth a deliberate opt-in decision before this ships, unlike e.g. filesystem access which is already opt-in via -V/-a.

Scope

Research/design only for now -- no implementation plan committed yet. Copperline's hostsocket-plugin (specifically its host-backend transport, not its default smoltcp stack) is the closest real precedent and worth reading in full before designing volamos's own approach.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions