gazagnaire.org / ocaml-solo5
Solo5 hvt ABI and MFT1/ABI1 note format as wire codecs
0
Fork 0

Configure Feed

Select the types of activity you want to include in your feed.

docs: make package taglines accurate and consistent

Several synopses had drifted from the code (mirage-eio is backend-agnostic,
not Solo5-only; nox-quic ships HTTP/3; squashfs writes as well as reads) and
varied in style. Describe each package by what it does rather than through
its eio, mirage or solo5 consumer, and apply the house synopsis conventions:
no leading article, spec ids in trailing parens. Also corrects a few factual
description and tag errors.

author
Thomas Gazagnaire date (Jul 7, 2026, 8:11 PM UTC) commit 56ea4105 parent 96b8eea7
+8 -8
+4 -4
dune-project
··· 13 13 14 14 (package 15 15 (name solo5-abi) 16 - (synopsis "The Solo5 hvt ABI and MFT1/ABI1 note format as wire codecs") 16 + (synopsis "Solo5 hvt ABI and MFT1/ABI1 note format as wire codecs") 17 17 (tags (org:blacksun system)) 18 18 (description 19 19 "The Solo5 hvt ABI and on-disk note formats, decoded and encoded with wire codecs and no I/O beyond ELF parsing: the hypercalls, boot info and argument structs, the MFT1 application manifest, and the Solo5 ABI note. Shared by the tenders and the manifest tooling so the format is defined once.") ··· 61 61 (package 62 62 (name solo5-hvf) 63 63 (allow_empty) 64 - (synopsis "A Solo5 hvt tender for macOS on Apple silicon") 64 + (synopsis "Solo5 hvt tender for macOS on Apple silicon") 65 65 (tags (org:blacksun system)) 66 66 (description 67 67 "Runs Solo5 hvt-ABI unikernels natively on Apple silicon via Apple's Hypervisor.framework. The hypervisor boundary (vCPU, guest memory, exits) is a small C stub; the ELF loader, manifest and ABI decoding, aarch64 page tables and the hypercall dispatch loop are pure OCaml. Upstream Solo5 has no macOS backend, so this is a standalone tender, not a Solo5 fork.") ··· 78 78 79 79 (package 80 80 (name solo5-slirp) 81 - (synopsis "A user-mode slirp network gateway for Solo5 tenders") 81 + (synopsis "User-mode slirp network gateway for Solo5 tenders") 82 82 (tags (org:blacksun system)) 83 83 (description 84 84 "A standalone user-mode network gateway for Solo5 tenders. A tender started with --net=slirp connects over a Unix SOCK_SEQPACKET socket and exchanges one Ethernet frame per datagram; the daemon runs an ocaml-slirp gateway per connection, answering ARP, leasing the guest a DHCP address, and terminating its outbound TCP/UDP/ICMP on unprivileged host sockets. Keeping the gateway out of the tender process is what lets a Linux tender confine itself to upstream Solo5's exact seccomp allowlist, since the host sockets live in this daemon rather than the tender.") ··· 95 95 (package 96 96 (name solo5-kvm) 97 97 (allow_empty) 98 - (synopsis "A Solo5 hvt tender for Linux via KVM") 98 + (synopsis "Solo5 hvt tender for Linux via KVM") 99 99 (tags (org:blacksun system)) 100 100 (description 101 101 "Runs Solo5 hvt-ABI unikernels on Linux (aarch64) via KVM (/dev/kvm). The hypervisor boundary (vCPU, guest memory, exits) is a small C stub of KVM ioctls; the ELF loader, manifest and ABI decoding, aarch64 page tables and the hypercall dispatch loop are pure OCaml, shared with solo5-hvf through solo5-tender. An OCaml counterpart to upstream Solo5's C hvt KVM tender.")
+1 -1
solo5-abi.opam
··· 1 1 # This file is generated by dune, edit dune-project instead 2 2 opam-version: "2.0" 3 - synopsis: "The Solo5 hvt ABI and MFT1/ABI1 note format as wire codecs" 3 + synopsis: "Solo5 hvt ABI and MFT1/ABI1 note format as wire codecs" 4 4 description: 5 5 "The Solo5 hvt ABI and on-disk note formats, decoded and encoded with wire codecs and no I/O beyond ELF parsing: the hypercalls, boot info and argument structs, the MFT1 application manifest, and the Solo5 ABI note. Shared by the tenders and the manifest tooling so the format is defined once." 6 6 maintainer: ["Thomas Gazagnaire <thomas@gazagnaire.org>"]
+1 -1
solo5-hvf.opam
··· 1 1 # This file is generated by dune, edit dune-project instead 2 2 opam-version: "2.0" 3 - synopsis: "A Solo5 hvt tender for macOS on Apple silicon" 3 + synopsis: "Solo5 hvt tender for macOS on Apple silicon" 4 4 description: 5 5 "Runs Solo5 hvt-ABI unikernels natively on Apple silicon via Apple's Hypervisor.framework. The hypervisor boundary (vCPU, guest memory, exits) is a small C stub; the ELF loader, manifest and ABI decoding, aarch64 page tables and the hypercall dispatch loop are pure OCaml. Upstream Solo5 has no macOS backend, so this is a standalone tender, not a Solo5 fork." 6 6 maintainer: ["Thomas Gazagnaire <thomas@gazagnaire.org>"]
+1 -1
solo5-kvm.opam
··· 1 1 # This file is generated by dune, edit dune-project instead 2 2 opam-version: "2.0" 3 - synopsis: "A Solo5 hvt tender for Linux via KVM" 3 + synopsis: "Solo5 hvt tender for Linux via KVM" 4 4 description: 5 5 "Runs Solo5 hvt-ABI unikernels on Linux (aarch64) via KVM (/dev/kvm). The hypervisor boundary (vCPU, guest memory, exits) is a small C stub of KVM ioctls; the ELF loader, manifest and ABI decoding, aarch64 page tables and the hypercall dispatch loop are pure OCaml, shared with solo5-hvf through solo5-tender. An OCaml counterpart to upstream Solo5's C hvt KVM tender." 6 6 maintainer: ["Thomas Gazagnaire <thomas@gazagnaire.org>"]
+1 -1
solo5-slirp.opam
··· 1 1 # This file is generated by dune, edit dune-project instead 2 2 opam-version: "2.0" 3 - synopsis: "A user-mode slirp network gateway for Solo5 tenders" 3 + synopsis: "User-mode slirp network gateway for Solo5 tenders" 4 4 description: 5 5 "A standalone user-mode network gateway for Solo5 tenders. A tender started with --net=slirp connects over a Unix SOCK_SEQPACKET socket and exchanges one Ethernet frame per datagram; the daemon runs an ocaml-slirp gateway per connection, answering ARP, leasing the guest a DHCP address, and terminating its outbound TCP/UDP/ICMP on unprivileged host sockets. Keeping the gateway out of the tender process is what lets a Linux tender confine itself to upstream Solo5's exact seccomp allowlist, since the host sockets live in this daemon rather than the tender." 6 6 maintainer: ["Thomas Gazagnaire <thomas@gazagnaire.org>"]