Some backstory: I have been using Claude Code to plan out and research whether Sun's SunRay thin-client architecture could be replicated as a modern Wayland compositor. During that process I kept getting this gut feeling that SPARC's throughput computing design could handle this kind of workload — and my neuro-symbolic AI experiment (akh-medu) — more efficiently than what we have today. But I also knew that with all the improvements in modern CPUs and GPUs, a direct comparison was not really fair anymore. The old hardware is gone, the ISA is dead, and the ecosystem moved on.

So I posed a side research question to Claude: What from SPARC's design philosophy is actually worth salvaging? And what does RISC-V already have that could carry those ideas forward? This post is the result of that research session. Claude helped me survey the RISC-V many-core landscape, pull together specs, summarize architectural details, and do the math on theoretical performance. I then wrote up what I found interesting and where I think the real opportunity is. The research legwork is AI-assisted, the opinions and the architectural instinct are mine.

This is going to be a long one. Grab a coffee.

The Throughput Computing Thesis

In 2005, while Intel was chasing single-thread performance with ever-deeper out-of-order pipelines, Sun went the opposite direction. Their bet: most server workloads are memory-latency-bound, not compute-bound. Instead of making one thread fast, make many threads always busy.

The T1 had 8 cores with 4 hardware threads each (32 total). Each core was deliberately simple — a 6-stage in-order pipeline. When thread A stalls on a cache miss, the core instantly switches to thread B. Zero-cycle context switch, because all thread state lives in dedicated hardware registers.

The T2 doubled down: 8 cores, 8 threads each, 64 hardware threads. Added per-core FPUs, integrated crypto engines (AES, SHA, RSA in hardware), and dual 10GbE MACs on-die.

Here is the thing that blew my mind when I actually looked at the scheduling logic: this is conceptually identical to how GPU warp scheduling works. An NVIDIA SM has 32-thread warps; when one warp stalls on memory, it switches to another. SPARC T-series was doing the same thing, except each thread ran a fully independent instruction stream (MIMD) rather than lockstep SIMT. Every thread could branch independently, chase pointers through graphs, run different code. No warp divergence penalty.

Why SPARC Lost (And Why It Doesn't Matter)

SPARC did not lose on architecture. It lost on ecosystem lock-in (x86 had all the software), single-thread expectations (most 2000s workloads were poorly parallelized), Oracle's mismanagement after the Sun acquisition, and economies of scale.

But what has changed since then:

• Parallelism is mandatory now. Games need 8+ threads. AI inference is embarrassingly parallel. The "most workloads are single-threaded" argument is dead.
• ISA matters less. Everything compiles from portable source. Apple proved you can switch architectures and the world follows. Rust does not care what ISA you target.
• Memory bandwidth is THE bottleneck. LLM inference is almost entirely memory-bandwidth-limited. This is exactly where SPARC's latency-hiding design excels.
• The CPU-GPU split is painful. PCIe transfers, synchronization, separate memory spaces, different programming models. The industry is spending enormous effort papering over a fundamentally broken architecture.

The Unified Memory Argument

This is where things get really interesting for practical workloads. Every time data crosses the PCIe bus between CPU and discrete GPU, you pay a bandwidth tax (PCIe 5.0 x16 gives ~50 GB/s vs HBM3E's 3.35 TB/s — a 67x cliff), a latency tax (1-10 microseconds with DMA vs 30-100 nanoseconds for local memory), a synchronization tax, and a programming model tax (two languages, two toolchains, two sets of bugs).

Where This Hurts: Thin-Client Compositors

Consider a thin-client compositor pipeline — something like a modern Wayland-based successor to SunRay that renders, encodes, compresses and streams frames to remote clients. This is the kind of thing I have been researching with Claude Code. Every frame does something like:

Wayland clients submit buffers
        → Compositor composites (CPU or GPU)
        → Frame capture (if GPU rendered: GPU→CPU copy!)
        → H.264/AV1 encode (if GPU encode: CPU→GPU copy!)
        → Compressed bitstream
        → zstd compress (CPU)
        → QUIC packetize + TLS encrypt (CPU)
        → Network transmit
        

With a discrete GPU, the render-to-encode path crosses PCIe twice per frame unless you carefully keep everything on the GPU side — which means your compositor logic also needs to run on the GPU, in a different programming model.

With true UMA, this becomes: everything reads and writes the same memory. Zero copies. One programming model. One address space. The entire pipeline is just functions passing references.

Where This Hurts: Neuro-Symbolic AI

The other workload that got me thinking about this is neuro-symbolic AI. I have been experimenting with akh-medu, a system that combines LLM inference with knowledge graph traversal and symbolic reasoning. The compute profile of this kind of workload is exactly where the CPU-GPU split hurts the most:

On a discrete GPU, a neuro-symbolic query involves four PCIe round-trips — embedding on GPU, back to CPU for graph traversal (can not do irregular access on GPU), back to GPU for language generation, back to CPU for the final answer. At 5-10 microseconds each with DMA overhead, that is 20-40+ microseconds of pure waste per query.

On a many-core UMA chip, you just partition cores by task. LLM cores, graph cores, reasoning cores, all sharing the same HBM. Zero copies. Zero synchronization overhead. Functions call each other. It is just Rust.

The graph traversal is particularly interesting here. Graph databases are notoriously GPU-hostile because memory access patterns are irregular (follow pointer, read node, follow next pointer), each step depends on the previous one, and nodes are scattered across memory. These are exactly the patterns that hardware multithreading was designed for. When a core's thread 0 chases a pointer and misses cache, thread 1 immediately runs. Eight threads per core means 8 concurrent graph walks in flight, hiding all those cache misses.

What Apple and NVIDIA Already Proved

Apple's M-series is the strongest existence proof that UMA works. M4 Ultra runs ~819 GB/s unified memory shared by CPU, GPU, Neural Engine, and media engines. Final Cut Pro on M-series beats discrete-GPU workstations costing 3x more precisely because the render-encode pipeline has zero copies.

NVIDIA conceded the point too. Grace Hopper connects CPU and GPU via NVLink-C2C at 900 GB/s with cache coherency. AMD's MI300A fuses CPU and GPU dies sharing the same HBM pool.

The industry is converging. The question is whether you can leapfrog to a cleaner architecture.

The 2K-Core Architecture Sketch

So what would this actually look like? Here is where I let myself dream a little:

2,048 RISC-V cores @ 1.5-2.0 GHz
        8 hardware threads per core = 16,384 hardware threads
        Per-core: 256-bit RVV vector FPU (8x FP32/cycle)
        Per-core: 8KB L1I + 8KB L1D (intentionally small)
        
        Clustered into 128 tiles of 16 cores each
        Per-tile: 512KB shared L2
        
        Tiles connected via 2D mesh Network-on-Chip
        Shared L3: 256MB (on-package HBM-backed)
        
        Memory: 4-8 HBM3E stacks
        Bandwidth: 2-4 TB/s
        Capacity: 64-128 GB
        UMA: every core sees the same physical address space
        

Theoretical FP32 throughput with 256-bit RVV and FMA: ~65 TFLOPS. For reference, an NVIDIA H100 SXM does ~60 TFLOPS FP32 (but behind PCIe for CPU workloads), and Apple M4 Ultra GPU does ~27 TFLOPS (but with UMA). Our hypothetical gets competitive TFLOPS with UMA and fully general-purpose cores.

The 16,384 hardware threads are all fully independent MIMD — no divergence penalty. For irregular workloads (graph traversal, symbolic reasoning, protocol processing), effective thread utilization could be 3-5x higher than GPU despite fewer threads.

Why in-order cores? They are ~0.1mm² in 5nm versus ~1-2mm² for out-of-order. You fit 10-20x more per die. Power per thread is 5-10x lower. Latency is deterministic (important for real-time compositing and protocol deadlines). And the 8 hardware threads per core hide memory latency the same way GPU warps do.

What to Take from SPARC, What to Leave

The valuable innovations from SPARC T-series are microarchitectural, not ISA-level. Fine-grained hardware multithreading, crossbar memory interconnect, zero-cycle thread switching — none of these are ISA-dependent. They port cleanly to RISC-V.

What to drop: Register windows (waste die area, no benefit with modern L1 caches), the SPARC ISA itself (RISC-V has better toolchains), SPARC VIS vectors (RVV 1.0 is strictly superior), and the GPL license (RISC-V's BSD license enables both FLOSS and commercial use).

The OpenSPARC T1 source is unfortunately no longer easily available online (thanks Oracle). But the architectural ideas live on in OpenPiton, which started with OpenSPARC T1 cores and now supports RISC-V. If you want to study how SPARC's thread scheduling and crossbar design worked and see it applied to modern silicon, that is your starting point.

What You Can Hack On Today

This is not purely theoretical. The components exist in open source.

FPGA Proof-of-Concept (~$2K-$10K): Take a Xilinx Alveo U280 or U55C (HBM-equipped FPGA), pick an open RISC-V core (CVA6 from ETH Zurich or Snitch which was designed for many-core), add hardware multithreading by duplicating the register file and PC 4-8 times with a thread scheduler. Then tile and replicate using OpenPiton from Princeton — which started with OpenSPARC T1 cores and now supports RISC-V. OpenPiton is the real gem here. It provides the mesh interconnect, cache coherence, and memory controller integration all in one framework. Boot Linux or illumos on 16-64 cores and measure scaling behavior.

Simulation at Scale: gem5 can model thousands of RISC-V cores. FireSim from UC Berkeley runs on AWS F1 FPGA instances and can simulate hundreds of cores at near-real-time speeds.

Ride Existing Silicon: Esperanto Technologies built a 1,088 RISC-V core chip (ET-SoC-1 on TSMC 7nm), founded by Dave Ditzel — former Sun chief SPARC architect. This is literally the spiritual successor to SPARC Niagara rebuilt on RISC-V. Tenstorrent under Jim Keller is building RISC-V many-core with mesh NoC and matrix units. ETH Zurich's Occamy taped out 432 Snitch RISC-V cores in GlobalFoundries 12nm with open-source RTL.

illumos Thread Scheduler: illumos already has sophisticated thread scheduling (processor sets, lgroups, FSS scheduler) inherited from Solaris, which was tuned for SPARC T-series hardware threads. If someone builds RISC-V hardware with SPARC-style multithreading, illumos is arguably the best OS to run on it. The cmt.c and pg.c code already distinguishes hardware threads from cores from sockets. That is a head start nobody else has.

So How Crazy Am I?

Look, I am not going to pretend I am going to tape out a 2,048-core chip in my garage. But I also do not think this is pure fantasy. The core ideas — throughput computing, hardware multithreading, unified memory — are validated. SPARC T-series proved the architecture works. Apple proved UMA wins for mixed workloads. Esperanto and ETH Zurich proved you can build many-core RISC-V and it actually boots. The pieces exist.

What I honestly do not know yet is whether the software side is tractable. Getting compilers to do the right thing for thousands of in-order cores is not a solved problem. OS scheduler support needs real work — though illumos has a head start there because Solaris was tuned for exactly this kind of hardware. And developer tooling for debugging 16,000 hardware threads... yeah, that is going to be interesting.

If someone wanted to actually pursue this, a realistic path could look like: study the OpenSPARC design decisions through OpenPiton, prototype some hardware multithreading on a RISC-V core on an FPGA, and benchmark workloads like the SunRay-style compositor pipeline or neuro-symbolic queries against a discrete GPU setup. See if the numbers back up the gut feeling. And honestly, keep watching what Esperanto and Tenstorrent ship. If their silicon lands and performs well, you might not need custom hardware at all. Just adapt the software stack.

But even if nobody builds this exact chip, I think the design direction matters. We keep bolting more heterogeneous accelerators onto systems and then spending half our engineering time on the glue between them. At some point it is worth asking: what if the cores were just good enough at everything that you did not need the split? Not the fastest at any one thing. But fast enough at all of them, in one address space, with one programming model.

Not a GPU killer. Not a CPU killer. Something in between that makes the distinction irrelevant for the workloads that actually need both.

If any of this makes you want to dig into OpenPiton or start tinkering with Snitch clusters — I would love to hear about it. And if you know people at Esperanto or Tenstorrent who want to talk about workload profiles for this kind of architecture, point them my way.

A note on process: The workload analysis, detailed writeups, performance numbers, spec comparisons, and ecosystem survey in this post were compiled with help from Claude Code. I find AI is genuinely good for this kind of legwork — pulling together scattered specs, summarizing source code, doing back-of-envelope math, and writing up the detailed technical sections. The opinions and the conviction that this design philosophy deserves a second look are mine. As always, verify the numbers before betting hardware budgets on a blog post.

Hope to talk to some folks on Socials and email.

-- Toasty

In quite a few cases when I have a few specific questions about a topic, I find that a very specific guide has not been made by anyone for it. Like in this case where I wondered. So how actaually could you make a virtiofs driver for illumos in Rust. With Gemini DeepResearch mode I often found it made me such articles and that I enjoyed reading them. And since I enjoyed the read I figured other might aswell.

An Architectural and Implementation Blueprint for a virtiofs Kernel Driver in Rust on illumos

Architectural Foundations: The virtiofs Device and FUSE Protocol

This report provides a detailed architectural blueprint for the implementation of a VIRTIO Filesystem (virtiofs) kernel driver for the illumos operating system. The implementation is predicated on the use of the Rust programming language, introducing specific challenges and design patterns related to kernel-space programming, Foreign Function Interface (FFI) management, and operating system-specific integration.

Analysis of the VIRTIO v1.2 Specification

The virtiofs device is a paravirtualized filesystem interface formally defined within the OASIS VIRTIO (Virtual I/O Device) 1.2 specification.¹ The VIRTIO standard, in general, provides a "straightforward, efficient, standard and extensible mechanism for virtual devices".⁴ The virtiofs device, specifically, is designed to provide high-performance, local filesystem semantics for guest virtual machines to access a directory tree on the host.⁶
The virtiofs device is identified by the VIRTIO Device ID 26.9 Like all VIRTIO devices, it is transport-agnostic and can be exposed to the guest operating system over a virtual PCI bus 5 or via a Memory-Mapped I/O (MMIO) interface.¹⁰
A critical architectural prerequisite for this project is the existing VIRTIO nexus framework within the illumos kernel, virtio(4D).¹¹ This generic driver is not a device driver itself, but a nexus (bus) driver. Its documented purpose is to "provide a framework for other device drivers" and to manage "feature negotiation, virtqueue management, used and available rings, interrupts, and more".¹¹
Analysis of the illumos-gate source repository 12 confirms this structure; existing VIRTIO client drivers, such as vioblk.c for block devices 12 and vioif.c for network devices 12, are implemented as clients of this virtio(4D) framework.
Therefore, the Rust virtiofs driver must not attempt to implement the raw PCI or MMIO transport-level logic. To do so would be redundant and architecturally incorrect, bypassing the established kernel framework. The correct design is to implement the Rust driver as a client of the virtio(4D) nexus. This significantly simplifies the project, abstracting away the low-level hardware interaction. The driver's FFI bridge will target the internal C-language API exposed by the virtio(4D) framework, not the lower-level DDI/DKI functions for PCI device management.

The FUSE-in-VIRTIO Protocol

The fundamental design of virtiofs is the tunneling of the Linux FUSE (Filesystem in Userspace) protocol over the VIRTIO transport mechanism.⁷ This design dictates a specific set of roles:

• Guest Driver (Our Rust Code): Acts as the FUSE client.¹⁰
• Host-side Components (e.g., QEMU + virtiofsd): Act as the FUSE file system daemon.⁶

The filesystem session is initiated by the driver, after VIRTIO initialization, by sending a FUSE_INIT request message on one of the standard request virtqueues.¹⁰
This architecture represents a "security inversion" from the traditional FUSE model. In a standard FUSE implementation (e.g., on Linux or FreeBSD) 17, the kernel driver is the trusted entity, and the userspace daemon that implements the filesystem logic is untrusted.⁶ In the virtiofs model, this is reversed: the guest kernel (and our driver) is the untrusted client.⁶ The host-side virtiofsd daemon is a hardened implementation that must not trust the client.⁶
This security inversion has profound and beneficial implications for this project. The illumos driver is not responsible for complex filesystem logic, data integrity, or permission checks. That entire logical burden is offloaded to the host virtiofsd daemon.⁶ The driver's sole responsibility is to be a correct protocol translator, converting illumos VFS (Virtual File System) requests into FUSE protocol opcodes 20 and VIRTIO transport messages. This constrained responsibility and minimal attack surface make virtiofs an ideal candidate for a novel implementation in Rust, as the most complex and potentially unsafe logic is handled externally by the host.

Virtqueue Structure and Operation

All communication between the driver (client) and the device (daemon) occurs via virtqueues.¹ This is a standard VIRTIO mechanism based on shared memory rings. The driver places descriptors in an "available" ring for the device to consume and asynchronously processes "used" descriptors that the device writes back after completing a request.¹⁰
The virtiofs specification defines a specific set of virtqueues 9:

• Virtqueue 0: hiprio (a high-priority request queue)
• Virtqueue 1: notification queue
• Virtqueues 2..n: request queues (standard FUSE requests)

The notification queue (vq 1) exists only if the device offers, and the driver negotiates, the VIRTIO_FS_F_NOTIFICATION feature bit.¹⁰ If this feature is active, the driver must populate this queue with empty buffers to receive asynchronous FUSE notify messages from the host, such as a "file changed" event.

The High-Priority Queue (hiprio)

The hiprio queue is an essential mechanism designed to solve a fundamental semantic mismatch between FUSE and VIRTIO.

• The Problem: The standard FUSE interface (via /dev/fuse) allows a client to select which request to transfer, enabling prioritization of critical requests.⁸ VIRTIO virtqueues, however, are strictly FIFO (First-In, First-Out) structures.²⁵
• The Deadlock: This mismatch can lead to a kernel deadlock. For example, if a standard request queue (e.g., vq 2) is full of large, slow FUSE_READ operations, the VFS may need to reclaim a vnode. To do this, it must send a FUSE_FORGET message. If this message is enqueued on the same full request queue, it will be stuck behind the data operations. The vnode will never be reclaimed, and the system will deadlock. A similar priority-inversion problem occurs with FUSE_INTERRUPT (e.g., from a user pressing Ctrl+C).
• The Solution: The hiprio queue (vq 0) provides an out-of-band, high-priority channel specifically for these non-data-path critical messages.⁸ The driver MUST submit FUSE_INTERRUPT, FUSE_FORGET, and FUSE_BATCH_FORGET requests only on the hiprio queue.²¹

The Linux kernel's virtiofs driver implements its hiprio queue with a polling mechanism for responses, rather than relying on interrupts. This is justified by the specification, which notes these messages are "high importance and low bandwidth".²¹ This suggests that a complex, interrupt-driven state machine for this queue is unnecessary.
Consequently, the Rust driver should be designed with two distinct request-processing pipelines:

1. An asynchronous, interrupt-driven, high-throughput pipeline for the main request queues (vq 2+).
2. A simpler, potentially synchronous or polling-based pipeline for the hiprio queue (vq 0). This isolates the critical cache-management and cancellation logic from the bulk data path, simplifying the implementation of both.

The Target Environment: illumos DDI/DKI and VFS

The Rust driver must integrate natively with the illumos kernel, satisfying the interfaces defined by the DDI/DKI (Device Driver Interface / Driver-Kernel Interface) and the VFS.

The illumos Driver Lifecycle (DDI/DKI)

The illumos DDI/DKI provides a set of stable, long-term kernel ABIs.²⁶ This stability is what makes out-of-tree driver development feasible, as a driver written against the DDI/DKI will continue to function across kernel updates.²⁹
As a loadable kernel module, the driver must export three standard C-linkage symbols 31:

1. _init(void): Called when the module is loaded. Its primary responsibility is to call mod_install(9F).³³
2. _fini(void): Called when the module is to be unloaded. It must call mod_remove(9F).³³
3. _info(struct modinfo *): Called by the system to retrieve information about the module.³¹

These functions are bundled into a struct modlinkage.³⁴ For a device driver, this modlinkage structure points to a struct modldrv, which in turn contains a struct dev_ops holding the driver's autoconfiguration entry points.

Device Discovery and Attachment

As established, the virtiofs driver will be a client of the virtio(4D) nexus. The dev_ops structure will define the driver's implementation of the DDI autoconfiguration routines, most importantly the attach(9E) entry point.³⁵
When the virtio(4D) nexus driver probes a VIRTIO device and identifies it as a virtiofs device (ID 26), it will invoke this driver's attach function. This function receives a dev_info_t *dip (device info pointer).³⁵ This dip is the opaque handle that the Rust FFI layer will use for all subsequent interactions with the DDI, and specifically with the virtio(4D) framework.
The implementation will require careful analysis of the attach routines in the C-based vioblk.c 13 and vioif.c 14 drivers within the illumos-gate repository. This analysis will reveal the exact internal virtio(4D) API functions (e.g., virtio_queue_setup, virtio_feature_negotiate) that must be bound via FFI to initialize the device.

VFS Integration

In parallel with its role as a device driver, the module must also register itself as a new filesystem type with the VFS.

• vfs_switch Table: The driver must define a static struct vfssw (VFS switch table).³⁶ This C structure contains function pointers for VFS-level operations, most notably vsw_mount, and a string name for the filesystem type (e.g., "virtiofs").
• Registration: During the _init routine, after mod_install succeeds, the driver must call vfs_add(9F) 36, passing a pointer to its vfssw struct. This kernel-wide registration is what enables the mount(2) system call, and thus the mount(8) command, to recognize "virtiofs" as a valid filesystem type.¹⁵

The vnodeops Interface: VFS-to-FUSE Translation

This is the logical core of the driver. The VFS performs all operations on files and directories through vnode (virtual node) objects.³⁷ Every vnode contains a v_op function vector, which points to a struct vnodeops.³⁹ The virtiofs driver must provide a complete implementation of this vnodeops structure.
This implementation will consist of a table of Rust functions exposed with a C ABI. Each function will be a translator: it will receive VFS arguments (e.g., a uio(9S) structure for a read), translate them into the corresponding FUSE request message, dispatch that message on a request virtqueue, and then block until a response is received from the host.
This VFS-to-FUSE translation is a solved problem and should not be re-engineered from first principles. The implementation must draw from two primary reference sources:

1. illumos-fusefs: This existing FUSE driver for illumos 42 contains the C-language fuse_vfs.c and fuse_vnode.c.⁴⁴ These files provide the exact logic for translating illumos vnodeops into FUSE opcodes. This is the primary reference for the illumos VFS side of the bridge.
2. Linux virtiofs Driver: The Linux kernel's virtiofs driver 8 and its source code (e.g., fs/fuse/virtio_fs.c 47) provide the reference model for integrating FUSE client logic with the VIRTIO transport.

The following table defines the primary translation work-list, mapping illumos vnodeops to their virtiofs FUSE opcode counterparts.

The Rust-in-Kernel Bridge: FFI and no_std Implementation

The primary challenge of this project is the use of Rust for kernel-space development. This requires a no_std environment and a meticulously crafted FFI bridge.

The no_std Kernel Environment

The Rust standard library (std) cannot be used in kernel space, as it relies on OS-provided services (e.g., userspace memory allocation, threads) that are not available.⁵⁰

• Crate Structure: The driver will be a Rust crate built with the #![no_std] attribute and a crate-type of ["cdylib", "rlib"]. It will depend on the core library (for Rust primitives) and the alloc library (for dynamic memory structures like Box and Vec).
• Global Allocator: The alloc crate requires a global allocator to be defined. The driver must provide an implementation of the GlobalAlloc trait that wraps the illumos kernel memory allocator: kmem_alloc(9F).⁵³

This allocator presents a significant and subtle safety challenge. The kmem_alloc(9F) API is context-dependent, controlled by its flag parameter.⁵³

• KM_SLEEP: The call is allowed to block (sleep) if memory is not immediately available. This is safe to use from kernel thread context (e.g., a vnodeop entry point) but will panic the system if called from interrupt context.
• KM_NOSLEEP: The call must not block. It will return NULL if memory is not available. This is the only flag allowed in high-level interrupt context.⁵³

The Rust GlobalAlloc trait is synchronous and has no concept of execution context. A naive implementation (e.g., one that always calls kmem_alloc with KM_SLEEP) will be unsafe and will panic the system if any part of the driver (e.g., an interrupt-handler callback) attempts to allocate memory. Conversely, a KM_NOSLEEP-only allocator would be highly inefficient and prone to failure.
This means a naive, global allocator is unusable. The driver's Rust code must be explicitly aware of its execution context. Standard Rust collections (e.g., Box, Vec, String) which rely on the GlobalAlloc can only be safely used from "thread context" (e.g., vnodeops, attach, taskq workers). Code running in "interrupt context" (e.g., the virtqueue "bottom half" handler) must be written to not allocate or to use a special, non-default KM_NOSLEEP-based allocator. This is a fundamental design constraint for ensuring memory safety.

Creating the DDI/DKI FFI Layer

A safe, idiomatic Rust driver must be built upon a set of unsafe FFI bindings to the illumos kernel.

• bindgen: The rust-bindgen tool 54 will be used to generate raw Rust bindings from the primary DDI/DKI C headers: <sys/ddi.h> 56, <sys/sunddi.h>, <sys/modctl.h> 33, <sys/kmem.h> 53, <sys/vnode.h> 57, <sys/vfs.h>, and the internal virtio.h header from the illumos-gate source.
• #[repr(C)] Structs: All C structs that are passed across the FFI boundary must be mirrored in Rust using the #[repr(C)] attribute.⁵⁸ This includes the top-level modlinkage 34, cb_ops 60, vfssw 36, and vnodeops 41 structures. This requirement is recursive; any nested struct must also be #[repr(C)].⁶¹

It is important to note that the existing illumos/rust-illumos crate 62 is intended for userspace development. Its dependent crates, such as doors 64, kstat-rs 65, and zone 66, wrap userspace libraries (libdoor, libkstat, etc.), not kernel-space DDI/DKI functions.
The correct precedent for this project is the work done by Oxide Computer.³⁰ Oxide's propolis VMM 67 contains internal crates, bhyve-api and viona-api 68, which are exactly what this project requires: no_std Rust FFI bindings for illumos kernel ioctls and C data structures. The FFI layer for the virtiofs driver should be architected following this pattern.

The FFI Binding Crate Plan

To manage complexity and promote safety, the raw unsafe bindings should be organized into logical Rust modules, which will then expose a safer, more idiomatic API to the main driver logic.

Implementation Blueprint: A virtiofs Driver in Rust

This implementation plan synthesizes the VIRTIO contract, the illumos DDI/VFS interfaces, and the Rust FFI bridge into a cohesive, phased driver implementation.

Phase 1: Driver Loading and VIRTIO Initialization (Rust attach)

1. _init: The driver's lib.rs will export a #[no_mangle] pub extern "C" function named _init.
2. mod_install: This _init function will, via FFI, call mod_install with a pointer to a #[repr(C)] static modldrv struct. This struct will point to the driver's dev_ops.
3. vfs_add: The _init function will also call vfs_add with a pointer to a #[repr(C)] static vfssw struct, registering "virtiofs" as a filesystem.
4. attach: The kernel will invoke the attach function (also #[no_mangle] pub extern "C") defined in the dev_ops. This Rust function will:
   a. Receive the dev_info_t* dip.
   b. Use this dip to call into the illumos_ffi::virtio wrapper.
   c. The wrapper's unsafe Rust code will call the C virtio(4D) framework functions to perform feature negotiation. It will assert that the host offers VIRTIO_F_VERSION_1 and request critical features like VIRTIO_FS_F_NOTIFICATION.¹⁰
   d. It will then initialize all required virtqueues (hiprio, notification, and one or more request queues) using the virtio_queue_setup FFI function.
   e. Upon success, it will instantiate the primary VirtioFsDriver Rust struct, populate it with the virtqueue handles and device state, and store it as the driver's private data.

Phase 2: VFS Mounting and FUSE Session (Rust vsw_mount)

1. A user process executes mount -t virtiofs....¹⁵
2. The kernel VFS layer follows the vfssw pointer and invokes the driver's vsw_mount Rust function.
3. This function is responsible for initiating the FUSE session by sending the FUSE_INIT message.¹⁰
4. It constructs the FUSE_INIT request, allocates a DMA-capable buffer using a wrapped virtio_dma_alloc or similar function from the virtio(4D) API, and places it on request vq 2.
5. It notifies the device via virtio_queue_notify and then blocks.
6. The block will be implemented by an FFI call to cv_wait on a kcondvar_t specific to this FUSE_INIT request.
7. The interrupt handler (Phase 3) will process the FUSE_INIT response and call cv_signal to wake this thread.
8. The vsw_mount function wakes up, validates the FUSE_INIT reply, creates the root vnode for the new filesystem, and returns success to the VFS.

Phase 3: The vnodeops Request-Response Engine (Rust VOP_READ)

This is the steady-state operation of the driver. VOP_READ is used as the canonical example for all I/O vnodeops.

1. A user process calls read(2) on a virtiofs file. The kernel traces this call through the vnode's v_op vector to the driver's vop_read Rust function.
2. Request State: The vop_read function (running in kernel thread context) executes:
   a. It generates a unique, 64-bit request ID.
   b. It creates a "waiter" struct. This struct contains a kcondvar_t, a pointer to the response buffer, and a status field.
   c. It inserts this waiter struct into a global, concurrent hash map (e.g., DashMap or a Mutex-guarded HashMap) keyed by the request ID.
   d. It serializes the FUSE_READ request, acquires a virtqueue descriptor, and enqueues the request on a request virtqueue.
   e. It calls virtio_queue_notify.
   f. It calls cv_wait (via FFI) on the kcondvar_t inside its waiter struct, putting the user thread to sleep.
3. The Interrupt Handler (Bottom Half):
   a. The host virtiofsd processes the request, places the response (the file data) in the used ring, and raises a virtual interrupt.²²
   b. The illumos virtio(4D) framework routes this to the driver's registered interrupt handler—a Rust function.
   c. This handler executes in high-priority interrupt context. It must not sleep or perform KM_SLEEP allocations.⁵³
4. The Interrupt-to-Taskq Pipeline:
   a. The interrupt handler's only job is to iterate the "used" ring, find the response descriptor, and extract the request ID from it.
   b. It must not perform the hash map lookup or cv_signal itself, as these operations are too complex and may block (on a mutex) for an interrupt context.
   c. Instead, the handler dispatches a "work item" (containing the response buffer and its request ID) to a kernel taskq(9F). This is done via a taskq_dispatch FFI call, which safely defers the work to a lower-priority kernel thread.
5. The taskq Worker (Middle Half):
   a. A generic kernel worker thread (in a safe, sleep-able context) picks up the work item.
   b. This Rust function (the taskq callback) performs the hash map lookup using the request ID.
   c. It finds the corresponding "waiter" struct, copies the response data into the waiter's buffer, and sets the status to "success."
   d. It calls cv_signal (via FFI) on the waiter's kcondvar_t.
6. VOP_READ Completion:
   a. Back in the vop_read function, the cv_wait call returns. The thread is now awake.
   b. It sees the status is "success" and its response buffer is populated.
   c. It uses an FFI call to uiomove to copy the data from the kernel response buffer into the user-space uio_t provided by the VFS.
   d. It removes the waiter from the DashMap and returns 0 (success) to the VFS.

Advanced Feature Implementation and Strategic Recommendations

Implementing DAX: The segmap Entry Point

The virtiofs Direct Access (DAX) feature is its primary performance advantage.⁶ It allows a guest to mmap(2) a file and map its contents directly from the host's page cache, eliminating the guest page cache and all FUSE_READ message overhead.⁷¹
This requires a highly specific implementation in illumos, bridging the VFS mmap path with the DDI device-mapping path.

1. The DAX Window: The virtiofs device exposes the DAX-capable memory as a shared memory region, typically a PCI BAR.⁶
2. The illumos API: The DDI/DKI entry point for mapping device memory (like a PCI BAR) into a user process's address space is segmap(9E).⁴⁹
3. The Protocol: The Linux virtiofs driver (which pioneered DAX) extended the FUSE protocol with FUSE_SETUPMAPPING and FUSE_REMOVEMAPPING opcodes.⁴⁸ The illumos driver must implement this part of the protocol.

Implementation Blueprint:

1. The driver's dev_ops structure will point to a cb_ops (char/block ops) structure 60, which will provide a function pointer for the segmap entry point.
2. A user process calls mmap(2) 75 on a virtiofs file.
3. The VFS determines this is a device-mapped file and calls the driver's segmap Rust function.
4. This segmap function (like vop_read) sends a FUSE_SETUPMAPPING request on a request virtqueue and blocks, awaiting the response.
5. The host virtiofsd performs the mapping on its side and returns a reply containing the offset and length of the file's data within the DAX Window (PCI BAR).⁶
6. The segmap function's interrupt/taskq handler populates the response. The segmap thread wakes up.
7. Now holding the device-relative offset and length, the segmap function makes a final FFI call to ddi_devmap_segmap(9F) 69 or devmap_setup(9F).⁷³
8. This DDI function performs the final, critical step: it takes the physical address (PCI BAR base + DAX offset) and instructs the kernel to map those physical pages directly into the user process's address space (struct as*).
9. The mmap(2) call returns a pointer to the user. Subsequent memory access to that pointer goes directly to the host's memory, requiring zero driver intervention or VM exits.

Build and Test Strategy

This driver cannot be built with a simple cargo build. It must be integrated into the illumos-gate build system.
The only proven model for building Rust kernel modules for illumos is the one pioneered by Oxide Computer.³⁰ cargo is not the primary build tool; it is a subprocess invoked by make.

1. Build System: The illumos-gate Makefile system 78 will be modified.
2. Rust Compilation: A Makefile rule will be added to invoke cargo build --release on the Rust crate, configured to produce a static library (e.g., libvirtiofs.a).
3. C Stub: A minimal C stub file (virtiofs_mod.c) will be created. This file will contain only the modlinkage boilerplate 34 and will reference the external Rust functions (e.g., virtiofs_attach, virtiofs_vop_read, etc.).
4. Linking: The illumos build system's linker 79 will be invoked to link the compiled C stub object (virtiofs_mod.o) against the Rust static library (libvirtiofs.a) to produce the final virtiofs loadable kernel module.

Testing and Debugging:

1. Host Environment: A QEMU 80 or bhyve 67 VM must be configured to run an illumos guest. The hypervisor must be configured to pass through a virtio-fs device and run the virtiofsd daemon on the host, sharing a directory.⁷
2. Guest Environment: The compiled virtiofs module must be loaded into the guest kernel, e.g., via add_drv(1M).⁸³
3. Debugging: The primary illumos debugging tools, mdb(1) (Modular Debugger) 84 and DTrace, will be essential. mdb -K 85 allows for live debugging of the kernel. For initial driver loading, QEMU's GDB stub (-s -S) 86 can be used to connect GDB at boot and step through the _init and attach routines.

Conclusions and Recommendations

The implementation of a virtiofs kernel driver in Rust for illumos is a complex but highly feasible and valuable project. The core complexity is not in the virtiofs protocol itself (which is a straightforward translation task), but rather in the creation of a safe, robust, and context-aware FFI bridge between the Rust no_std environment and the illumos DDI/DKI.
Key Recommendations:

1. Adopt the Oxide Precedent: The project must use the work from Oxide Computer (e.g., propolis, helios, and their networking stack drivers) as the primary and foundational reference.³⁰ Their solutions for FFI, no_std builds, and C-stub-plus-Rust-archive linking 30 are the only proven models for this environment.
2. Build a HAL, Not Just a Driver: The project should be architecturally partitioned. The primary deliverable is not just the virtiofs driver, but a reusable "illumos-hal" crate.
   • illumos_ffi crate: An unsafe crate containing raw, bindgen-generated bindings.
   • illumos_hal crate: A safe, idiomatic, no_std Rust crate that wraps the FFI layer. It would provide safe abstractions for kernel-space Mutex, Condvar, Taskq, and a context-aware kmem_alloc API.
   • virtiofs_driver crate: The virtiofs driver itself, written in pure, safe Rust against the illumos_hal API.
3. Prioritize FFI and Concurrency: The most difficult design challenges are the context-aware kmem_alloc wrapper (Insight 3.1.1) and the interrupt-to-taskq request-response pipeline (Insight 4.3.2). These concurrency and safety primitives must be designed and validated before FUSE logic is written.
4. Reference C Implementations: The logic for the VFS-to-FUSE translation must be ported from the existing illumos-fusefs C implementation 42 to ensure illumos-specific VFS semantics are preserved. The logic for the FUSE-to-VIRTIO transport must be ported from the Linux kernel virtiofs driver 47 to ensure protocol-level correctness.

By correctly leveraging the existing virtio(4D) nexus and the security-inversion model of FUSE, the driver's logic is simplified to that of a protocol translator. This bounded scope, combined with the memory safety guarantees of Rust, makes this an ideal project for demonstrating and hardening the use of Rust for kernel-space development on illumos.

Works cited

1. Virtio 1.2 is Coming! - Alibaba Cloud Community, accessed on November 4, 2025, https://www.alibabacloud.com/blog/virtio-1-2-is-coming_599615
2. VIRTIO 1.2 is out! · KVM, QEMU, and more - Red Hat People, accessed on November 4, 2025, https://people.redhat.com/~cohuck/2022/07/18/virtio-12-is-out.html
3. What's coming in VIRTIO 1.2 - Stefan Hajnoczi, accessed on November 4, 2025, https://vmsplice.net/~stefan/stefanha-fosdem-2022.pdf
4. oasis-tcs/virtio-docs: OASIS Virtual I/O Device TC: Development of formatted documents for the VIRTIO (Virtual I/O) Specification maintained by the OASIS VIRTIO Technical Committee - GitHub, accessed on November 4, 2025, https://github.com/oasis-tcs/virtio-docs
5. oasis-tcs/virtio-spec: OASIS Virtual I/O Device TC - GitHub, accessed on November 4, 2025, https://github.com/oasis-tcs/virtio-spec
6. Virtiofs Design Document, accessed on November 4, 2025, https://virtio-fs.gitlab.io/design.html
7. Virtio-FS, accessed on November 4, 2025, https://virtio-fs.gitlab.io/
8. virtiofs: virtio-fs host<->guest shared file system - The Linux Kernel documentation, accessed on November 4, 2025, https://docs.kernel.org/filesystems/virtiofs.html
9. Virtual I/O Device (VIRTIO) Version 1.2 - OASIS Open, accessed on November 4, 2025, https://docs.oasis-open.org/virtio/virtio/v1.2/csd01/virtio-v1.2-csd01.html
10. Virtual I/O Device (VIRTIO) Version 1.2 - Index of / - OASIS Open, accessed on November 4, 2025, https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.pdf
11. illumos: manual page: virtio.4d - SmartOS, accessed on November 4, 2025, https://smartos.org/man/4D/virtio
12. Illumos-gate - GitHub, accessed on November 4, 2025, https://github.com/illumos/illumos-gate
13. illumos-gate - Niksula, accessed on November 4, 2025, https://www.niksula.hut.fi/~ltirkkon/webrev/4330/
14. Package Catalogue - OmniOS, accessed on November 4, 2025, https://pkg.omniosce.org/r151022/core/en/catalog.shtml
15. virtio-fs - Stefan Hajnoczi, accessed on November 4, 2025, https://vmsplice.net/~stefan/virtio-fs_%20A%20Shared%20File%20System%20for%20Virtual%20Machines%20%28FOSDEM%29.pdf
16. virtiofs: virtio-fs host<->guest shared file system - The Linux Kernel Archives, accessed on November 4, 2025, https://www.kernel.org/doc/html/v5.14/filesystems/virtiofs.html
17. libfuse/libfuse: The reference implementation of the Linux FUSE (Filesystem in Userspace) interface - GitHub, accessed on November 4, 2025, https://github.com/libfuse/libfuse
18. Filesystem in Userspace - Wikipedia, accessed on November 4, 2025, https://en.wikipedia.org/wiki/Filesystem_in_Userspace
19. FUSE — The Linux Kernel documentation, accessed on November 4, 2025, https://www.kernel.org/doc/html/next/filesystems/fuse.html
20. DOCA SNAP Virtio-fs Application Guide - NVIDIA Docs, accessed on November 4, 2025, https://docs.nvidia.com/doca/sdk/doca+snap+virtio-fs+application+guide/index.html
21. Virtual I/O Device (VIRTIO) Version 1.1 - GitHub Pages, accessed on November 4, 2025, https://stefanha.github.io/virtio/virtio-fs.html
22. Virtqueues and virtio ring: How the data travels - Red Hat, accessed on November 4, 2025, https://www.redhat.com/en/blog/virtqueues-and-virtio-ring-how-data-travels
23. Improved Linux filesystem sharing for simulated devices with extended Virtio support in Renode, accessed on November 4, 2025, https://renode.io/news/improved-filesystem-sharing-with-virtiofs-support-in-renode/
24. DOCA DevEmu Virtio-FS - NVIDIA Docs Hub, accessed on November 4, 2025, https://docs.nvidia.com/doca/sdk/doca+devemu+virtio-fs/index.html
25. virtiofs: virtio-fs host<->guest shared file system — The Linux Kernel ..., accessed on November 4, 2025, https://www.kernel.org/doc/html/v5.9/filesystems/virtiofs.html
26. Development Titles - OpenIndiana Docs, accessed on November 4, 2025, https://docs.openindiana.org/books/develop/
27. illumos | Univrs, accessed on November 4, 2025, https://book.univrs.io/
28. illumos: manual page: intro.9e - SmartOS, accessed on November 4, 2025, https://smartos.org/man/9e/intro
29. Multi-Kernel Drifting - Hacker News, accessed on November 4, 2025, https://news.ycombinator.com/item?id=33337086
30. Rust in illumos - Hacker News, accessed on November 4, 2025, https://news.ycombinator.com/item?id=41505665
31. Device Driver Entry Points, accessed on November 4, 2025, https://docs.oracle.com/cd/E23824_01/html/819-3196/eqbqy.html
32. Driver Module Entry Points (Writing Device Drivers), accessed on November 4, 2025, https://docs.oracle.com/cd/E19683-01/806-5222/drvovr-fig-20/index.html
33. _fini - man pages section 9: DDI and DKI Driver Entry Points, accessed on November 4, 2025, https://docs.oracle.com/cd/E88353_01/html/E37854/u-fini-9e.html
34. how to make loadable kernel module on solaris? no linux - Stack Overflow, accessed on November 4, 2025, https://stackoverflow.com/questions/50733459/how-to-make-loadable-kernel-module-on-solaris-no-linux
35. ATTACH(9E) - OmniOS, accessed on November 4, 2025, https://man.omnios.org/man9e/attach
36. Steps in developing your own File system in Solaris 10 - Stack Overflow, accessed on November 4, 2025, https://stackoverflow.com/questions/41115181/steps-in-developing-your-own-file-system-in-solaris-10
37. VFS - OSDev Wiki, accessed on November 4, 2025, http://wiki.osdev.org/VFS
38. Virtual File Systems - IBM, accessed on November 4, 2025, https://www.ibm.com/docs/en/aix/7.2.0?topic=concepts-virtual-file-systems
39. vnode(9) - OpenBSD manual pages, accessed on November 4, 2025, https://man.openbsd.org/vnode.9
40. vnode(9), accessed on November 4, 2025, https://www.daemon-systems.org/man/vnode.9.html
41. vnodeops(9) - NetBSD Manual Pages, accessed on November 4, 2025, https://man.netbsd.org/vnodeops.9
42. alhazred/illumos-sshfs: illumos FUSE driver and library + ... - GitHub, accessed on November 4, 2025, https://github.com/alhazred/illumos-sshfs
43. [OmniOS-discuss] FW: Re: Mount NTFS USB under OmniOS, accessed on November 4, 2025, https://omnios.org/ml-archive/2013-January/000405.html
44. accessed on January 1, 1970, https://github.com/jurikm/illumos-fusefs
45. accessed on January 1, 1970, https://github.com/alhazred/illumos-sshfs/tree/master/kernel
46. [RFC] virtio-fs: shared file system for virtual machines - LWN.net, accessed on November 4, 2025, https://lwn.net/Articles/774495/
47. fs/fuse/virtio_fs.c - kernel/common - Git at Google - Android GoogleSource, accessed on November 4, 2025, https://android.googlesource.com/kernel/common/+/refs/heads/android12-5.4/fs/fuse/virtio_fs.c
48. virtiofs: Add DAX support - LWN.net, accessed on November 4, 2025, https://lwn.net/Articles/813807/
49. illumos: manual page: segmap.9e - SmartOS, accessed on November 4, 2025, https://www.smartos.org/man/9E/segmap
50. Rust Without the Standard Library A Deep Dive into no_std Development | Leapcell, accessed on November 4, 2025, https://leapcell.io/blog/rust-without-the-standard-library-a-deep-dive-into-no-std-development
51. Use cases for `no_std` on tier 1 targets - libs - Rust Internals, accessed on November 4, 2025, https://internals.rust-lang.org/t/use-cases-for-no-std-on-tier-1-targets/20592
52. Writing FreeBSD Kernel Modules in Rust | NCC Group, accessed on November 4, 2025, https://www.nccgroup.com/research-blog/writing-freebsd-kernel-modules-in-rust/
53. illumos: manual page: kmem_alloc.9f - SmartOS, accessed on November 4, 2025, https://www.smartos.org/man/9F/kmem_alloc
54. Binding a Linux API library : r/rust - Reddit, accessed on November 4, 2025, https://www.reddit.com/r/rust/comments/gt0j0q/binding_a_linux_api_library/
55. Bridging Rust and C Generating C Bindings and Headers with Cbindgen and Cargo-c, accessed on November 4, 2025, https://leapcell.io/blog/bridging-rust-and-c-generating-c-bindings-and-headers-with-cbindgen-and-cargo-c
56. illumos: manual page: ddi_flsll.9f - SmartOS, accessed on November 4, 2025, https://www.smartos.org/man/9f/ddi_flsll
57. NOTES.txt - Z IN ASCII, accessed on November 4, 2025, https://zinascii.com/pub/illumos/gate/1017/NOTES.txt
58. Other reprs - The Rustonomicon - Rust Documentation, accessed on November 4, 2025, https://doc.rust-lang.org/nomicon/other-reprs.html
59. question on `repr(C)` guarantees : r/rust - Reddit, accessed on November 4, 2025, https://www.reddit.com/r/rust/comments/1ap47sj/question_on_reprc_guarantees/
60. CB_OPS(9S) - OmniOS, accessed on November 4, 2025, https://man.omnios.org/man9s/cb_ops
61. `#[repr(C)]` on nested structs - help - The Rust Programming Language Forum, accessed on November 4, 2025, https://users.rust-lang.org/t/repr-c-on-nested-structs/110654
62. Rust wrappers for various illumos-specific system libaries - GitHub, accessed on November 4, 2025, https://github.com/illumos/rust-illumos
63. illumos repositories - GitHub, accessed on November 4, 2025, https://github.com/orgs/illumos/repositories
64. doors - Rust - Docs.rs, accessed on November 4, 2025, https://docs.rs/doors
65. kstat_rs - Rust - Docs.rs, accessed on November 4, 2025, https://docs.rs/kstat-rs
66. zone - Rust - Docs.rs, accessed on November 4, 2025, https://docs.rs/zone
67. Operating System and Virtualization Engineer - Oxide Computer, accessed on November 4, 2025, https://oxide.computer/careers/sw-host-virt
68. oxidecomputer/propolis: VMM userspace for illumos bhyve - GitHub, accessed on November 4, 2025, https://github.com/oxidecomputer/propolis
69. illumos: manual page: ddi_segmap_setup.9f - SmartOS, accessed on November 4, 2025, https://www.smartos.org/man/9f/ddi_segmap_setup
70. Implementing a virtio-blk driver in my own operating system - Stephen Brennan, accessed on November 4, 2025, https://brennan.io/2020/03/22/sos-block-device/
71. virtio-fs - Stefan Hajnoczi, accessed on November 4, 2025, https://vmsplice.net/~stefan/virtio-fs_%20A%20Shared%20File%20System%20for%20Virtual%20Machines.pdf
72. Using virtio-fs on a unikernel - QEMU, accessed on November 4, 2025, https://www.qemu.org/2020/11/04/osv-virtio-fs/
73. Mapping Device Memory (Writing Device Drivers), accessed on November 4, 2025, https://docs.oracle.com/cd/E19683-01/806-5222/character-27110/index.html
74. Mapping Device Memory - Writing Device Drivers, accessed on November 4, 2025, https://docs.oracle.com/cd/E18752_01/html/816-4854/character-16543.html
75. manual page: mmap.² - illumos - SmartOS, accessed on November 4, 2025, https://www.smartos.org/man/2/mmap
76. I'm part of the illumos core team and I'm quite keen to use Rust in the base of ... - Hacker News, accessed on November 4, 2025, https://news.ycombinator.com/item?id=41506892
77. oxidecomputer/helios: Helios: Or, a Vision in a Dream. A Fragment. - GitHub, accessed on November 4, 2025, https://github.com/oxidecomputer/helios
78. new/usr/src/cmd/intrd/Makefile - illumos - code review, accessed on November 4, 2025, https://cr.illumos.org/~webrev/0xffea/intrd-kernel-01/illumos-gate.pdf
79. So you want to cross compile illumos, accessed on November 4, 2025, https://artemis.sh/2023/02/21/so-you-want-to-cross-compile-illumos.html
80. virtiofs - shared file system for virtual machines / Standalone usage - GitLab, accessed on November 4, 2025, https://virtio-fs.gitlab.io/howto-qemu.html
81. Host Operating System & Hypervisor / RFD / Oxide: 26, accessed on November 4, 2025, https://26.rfd.oxide.computer/
82. Virtio-fs is amazing! (plus how I set it up) : r/VFIO - Reddit, accessed on November 4, 2025, https://www.reddit.com/r/VFIO/comments/i12uyn/virtiofs_is_amazing_plus_how_i_set_it_up/
83. Device Driver Tutorial - filibeto.org, accessed on November 4, 2025, https://www.filibeto.org/aduritz/truetrue/solaris10/device-driver-819-3159.pdf
84. illumos tools for observing processes - Dave Pacheco's Blog, accessed on November 4, 2025, https://www.davepacheco.net/blog/post/2012-08-04-illumos-tools-for-observing-processes/
85. Illumos: Getting Started with MDB | Johann 'Myrkraverk' Oskarsson, accessed on November 4, 2025, http://www.myrkraverk.com/blog/2014/04/illumos-getting-started-with-mdb/
86. How to debug the Linux kernel with GDB and QEMU? - Stack Overflow, accessed on November 4, 2025, https://stackoverflow.com/questions/11408041/how-to-debug-the-linux-kernel-with-gdb-and-qemu

pkgdepend dependency resolution overview (ELF, Python, JAR)

This document describes how pkgdepend analyzes files to infer package dependencies, based on the current source code in the pkg(5) repository. It is intended to guide a reimplementation of equivalent checks in Rust.

High-level Flow

• File classification: src/modules/portable/os_sunos.py:get_file_type() reads the first bytes of each payload and classifies as one of:
  • ELF for ELF objects (magic 0x7F 'ELF').
  • EXEC for text files starting with a shebang (#!).
  • SMF_MANIFEST for XML files recognized as SMF manifests.
  • UNFOUND or unknown for other cases. There is no specific JAR type.
• Dispatch: src/modules/publish/dependencies.py:list_implicit_deps_for_manifest() maps file types to analyzers:
  • ELF -> pkg.flavor.elf.process_elf_dependencies
  • EXEC -> pkg.flavor.script.process_script_deps
  • SMF_MANIFEST -> pkg.flavor.smf_manifest.process_smf_manifest_deps Unknown types are recorded in a "missing" map but not analyzed.
• The analyzers return a list of PublishingDependency objects (see src/modules/flavor/base.py) and a list of analysis errors. These are later resolved to package-level DependencyAction objects.
• Bypass rules: If pkg.depend.bypass-generate is set (manifest or action), dependency generation can be skipped or filtered (details below).
• Internal pruning: After file-level dependencies are generated, pkgdepend can drop dependencies that are satisfied by files delivered by the same package.
• Resolution to packages: Finally, dependencies on files are mapped to package FMRIs by locating which packages (delivered or already installed) provide the target files, following links where necessary.

Controlling Run Paths and Bypass

• pkg.depend.runpath (portable.PD_RUN_PATH): A colon-separated string.
  • May be set at manifest level (applies to all actions) and/or per action.
  • Verified by __verify_run_path(): must be a single string and not empty.
  • Per-action value overrides manifest-level value for that action.
  • For ELF analysis, the provided runpath interacts with defaults via the PD_DEFAULT_RUNPATH token (see below).
• pkg.depend.bypass-generate (portable.PD_BYPASS_GENERATE): a string or list of strings controlling path patterns to ignore when generating dependencies.
  • In list_implicit_deps_for_manifest():
    • If bypass contains a match-all pattern .* or ^.*$, analysis for that action is skipped entirely. A debug attribute is recorded: pkg.debug.depend.bypassed="<action path>:.*".
    • Otherwise, __bypass_deps() filters out any matching file paths from the generated dependencies. Patterns are treated as regex; bare filenames are expanded to .*/<name> and patterns are anchored with ^...$. Matching paths are recorded in pkg.debug.depend.bypassed; dependencies are updated to only contain the remaining full paths.

ELF Analysis (pkg.flavor.elf)

Reference: src/modules/flavor/elf.py

Inputs

• Action (file) with attributes:
  • path: installed path (no leading slash in manifests; code often prepends "/").
  • portable.PD_LOCAL_PATH: proto/build file to read.
  • portable.PD_PROTO_DIR: base dir of the proto area.
• pkg_vars: package variant template (propagated to dependencies).
• dyn_tok_conv: map of dynamic tokens to expansion lists (e.g. $PLATFORM).
• run_paths: optional run path list from pkg.depend.runpath (colon-split).

Steps

1. Verify file exists and is an ELF object (pkg.elf.is_elf_object). If not, return no deps.
2. Parse headers and dynamic info:
   • elf.get_info(proto_file) -> bits (32/64), arch (i386/sparc).
   • elf.get_dynamic(proto_file) ->
     • deps: list of DT_NEEDED entries; code uses [d[0] for d in deps].
     • runpath: DT_RUNPATH string (may be empty).
3. Build default search path rp:
   • Start with DT_RUNPATH split by :. Empty string becomes [].
   • dyn_tok_conv["$ORIGIN"] is set to "/" + dirname(installed_path) so $ORIGIN can be expanded in paths.
   • Kernel modules (installed_path under kernel/, usr/kernel, or platform/<platform>/kernel):
     • If runpath is set to anything except the specific /usr/gcc/<n>/lib case, raise RuntimeError. Otherwise runpath for kernel modules is derived as:
       • For platform paths, append /platform/<platform>/kernel; otherwise for each $PLATFORM in dyn_tok_conv append /platform/<plat>/kernel.
       • Append default kernel paths: /kernel and /usr/kernel.
       • If 64-bit, a kernel64 subdir is used to assemble candidate paths when constructing dependencies: arch -> i386 => amd64; sparc => sparcv9.
   • Non-kernel ELF:
     • Ensure /lib and /usr/lib are present; for 64-bit also add /lib/64 and /usr/lib/64.
4. Merge caller-provided run_paths:
   • If run_paths is provided, base.insert_default_runpath(rp, run_paths) is used. This replaces any PD_DEFAULT_RUNPATH token in run_paths with the default rp. If the token is absent, the provided run_paths fully override rp. Multiple PD_DEFAULT_RUNPATH tokens raise an error.
5. Expand dynamic tokens in rp:
   • expand_variables() recursively replaces $TOKENS using dyn_tok_conv.
   • Unknown tokens produce UnsupportedDynamicToken errors (non-fatal) which are returned in the error list.
6. For each DT_NEEDED library name d:
   • For each expanded run path p, form a candidate directory by joining p and d; for kernel64 cases, insert amd64/sparcv9 as appropriate; drop the final filename to retain only directories (run_paths for this dependency).
   • Create an ElfDependency(action, base_name=basename(d), run_paths=dirs, pkg_vars, proto_dir).

Semantics of ElfDependency

• Inherits PublishingDependency (see below). It resolves against delivered files by joining each run_path with base_name to form candidates.
• resolve_internal() is overridden to treat the case where no path resolves but a file with the same base name is delivered by this package as a WARNING instead of an ERROR (assumes external runpath will make it available). That sets pkg.debug.depend.*.severity=warning and marks variants accordingly.

Python and Script Analysis (pkg.flavor.script + pkg.flavor.python)

References

• src/modules/flavor/script.py
• src/modules/flavor/python.py

Shebang handling (script.py)

• For any file with a shebang (#!) and the executable bit set:
  • Extract interpreter path (first token after #!). If not absolute, record ScriptNonAbsPath error.
  • Normalize /bin/... to /usr/bin/... and add a ScriptDependency on that interpreter path (base_name = last component; run_paths = directory).
• If the shebang line contains the substring "python" (e.g. #!/usr/bin/python3.9), python-specific analysis is triggered by calling python.process_python_dependencies(action, pkg_vars, script_path, run_paths), where script_path is the full shebang line and run_paths is the effective pkg.depend.runpath for the action.

Python dependency discovery (python.py)

• Version inference:
  • Installed path starting with usr/lib/python<MAJOR>.<MINOR>/ implies a version (dir_major/dir_minor).
  • Shebang matching ^#!/usr/bin/(<subdir>/)?python<MAJOR>.<MINOR> implies a version (file_major/file_minor).
  • If the file is executable and both imply versions that disagree, record a PythonMismatchedVersion error and use the directory version for analysis.
  • Analysis version selection:
    • If installed path implies version, use that.
    • Else if shebang implies version, use that.
    • Else if executable but no specific version (e.g. #!/usr/bin/python), record PythonUnspecifiedVersion and skip analysis.
    • Else if not executable but installed under usr/lib/pythonX.Y, analyze with that version.
• Performing analysis:
  • If the selected version equals the currently running interpreter (sys.version_info), use in-process analysis:
    • Construct DepthLimitedModuleFinder with the install directory as the base and pass through run_paths (pkg.depend.runpath). The finder executes the local proto file (action.attrs[PD_LOCAL_PATH]) to discover imports.
    • For each loaded module, obtain the list of file names (basenames of the modules) and the directories searched (m.dirs). Create PythonDependency(action, base_names=module file names, run_paths=dirs,...).
    • Any missing imports are reported as PythonModuleMissingPath errors.
    • Syntax errors are reported as PythonSyntaxError.
  • If the selected version differs from the running interpreter:
    • Spawn a subprocess: "python. depthlimitedmf.py <install_dir> <local_file> [run_paths ...]".
    • Parse stdout lines:
      • "DEP <repr((names, dirs))>" -> add PythonDependency for those.
      • "ERR <module_name>" -> record PythonModuleMissingPath.
      • Anything else -> PythonSubprocessBadLine.
    • Nonzero exit -> PythonSubprocessError with return code and stderr.

JAR Archives

• There is no special handling of JAR files in the current implementation.
  • get_file_type() does not classify JARs and there is no flavor/jar module.
  • The historical doc/elf-jar-handling.txt mentions the idea of tasting JARs, but this has not been implemented in pkgdepend.
• Consequently, pkgdepend does not extract dependencies from .jar manifests or classpaths. Any Java/JAR dependency tracking must be handled out-of-band (e.g., manual packaging dependencies or future tooling).

PublishingDependency Mechanics (flavor/base.py)

• A PublishingDependency represents a dependency on one or more files located via a list of run_paths and base_names, or via an explicit full_paths list.
• It stores debug attributes under the pkg.debug.depend.* namespace:
  • .file (base names), .path (run paths) or .fullpath (explicit paths)
  • .type (elf/python/script/smf/link), .reason, .via-links, .bypassed, etc.
• possibly_delivered():
  • For each candidate path (join of run_path and base_name, or each full_path), calls resolve_links() to account for symlinks and hardlinks and to find real provided paths.
  • If a path resolves and the resulting path is among delivered files, the dependency is considered satisfied under the relevant variant combination.
• resolve_internal():
  • Checks if another file delivered by the same package satisfies the dependency (via possibly_delivered against the package’s own files/links).
  • If so, the dependency is pruned. Otherwise, the error is recorded, subject to ELF’s special warning downgrade noted above.

Resolving Dependencies to Packages (dependencies.py)

• add_fmri_path_mapping(): builds maps from paths to (PFMRI, variant combinations) for both the currently delivered manifests and the installed image (if used).
• resolve_links(path, files_dict, links, path_vars, attrs):
  • Recursively follows link chains to real paths, accumulating variant constraints along the way and generating conditional dependencies when a link from one package points to a file delivered by another.
• find_package_using_delivered_files():
  • For each dependency, computes all candidate paths (make_paths()), resolves them through links (resolve_links), groups results by variant combinations, and then constructs either:
    • type=require if exactly one provider package resolves the dependency, or
    • type=require-any if multiple packages could satisfy it.
  • Debug attributes include:
    • pkg.debug.depend.file/path/fullpath
    • pkg.debug.depend.via-links (colon-separated link chain per resolution)
    • pkg.debug.depend.path-id (a stable id grouping related path attempts)
  • Link-derived conditional dependencies (type=conditional) are emitted to encode that a dependency is only needed when a particular link provider is present.
• find_package(): tries delivered files first; if not fully satisfied and allowed, tries files installed in the current image.
• combine(), __collapse_conditionals(), __remove_unneeded_require_and_require_any():
  • Perform simplification and deduplication of the emitted dependencies and collapse conditional groups where possible.

Variants and Conversion to Actions

• Each dependency carries variant constraints (VariantCombinations). After generation and internal pruning, convert_to_standard_dep_actions() splits dependencies by unsatisfied variant combinations, producing standard actions.depend.DependencyAction instances ready for output.

Run Path Insertion Rule (PD_DEFAULT_RUNPATH)

• base.insert_default_runpath(default_runpath, run_paths) merges default analyzer-detected search paths with user-provided run_paths:
  • If run_paths includes the PD_DEFAULT_RUNPATH token, the default_runpath is spliced at that position.
  • If the token is absent, run_paths replaces the default entirely.
  • Multiple tokens raise MultipleDefaultRunpaths.

Notes for a Rust Implementation

• ELF:
  • Parse DT_NEEDED and DT_RUNPATH. Handle $ORIGIN (directory of installed path) and $PLATFORM expansion. Implement kernel module path rules and 64-bit subdir logic. Merge user run paths via PD_DEFAULT_RUNPATH rules.
  • Build dependencies keyed by base name with a directory search list.
  • When pruning internal deps, downgrade to warning if base name is delivered by the same package but no path matches.
• Python:
  • Determine Python version from installed path or shebang. Flag mismatches.
  • Execute import discovery with a depth-limited module finder; if the target version differs, spawn the matching interpreter to run a helper script and parse outputs. Include run_paths in module search.
• JAR:
  • No current implementation. Decide whether to add support or retain current behavior (no automatic JAR dependency extraction).
• General:
  • Implement bypass rules and debug attributes to aid diagnostics.
  • Implement link resolution and conditional dependency emission.
  • Respect variant tracking and final conversion to concrete dependency actions.

Cross-reference

• Historical note in doc/elf-jar-handling.txt discusses possible JAR handling, but the current codebase does not implement JAR dependency analysis.

With the recent rust in Linux events in the last couple of days, It's a good time to write up Rust in illumos. Both to spread the word a bit and also to set expectations for both sides (Rust and illumos/OpenIndiana devs) what is currently possible and what work would need to be invested to make things smooth. And also to let the rust community know about what illumos people were talking about.

What most of the talk currently is about, are the technical details. But we must not leave the social aspects out of it. Software distributions are not made by lone walkers but by groups of people. Bringing in a new language means facilitating change. And that means there are more topics to discuss than just API design. We are talking about impacts on the whole software lifecycle.

Linux DRM API design

Looking at the things people like Asahi Lina want to address inside the Linux Kernel with the Rust bindings and how she describes the issues with Locking I get the feeling something with DRM is not consistent. Looking into our code and our docs for this topic I can already see that things are more complex in the whole kernel than just "do X" We have some general recommendations but it's a case by case issue when looking at it over the whole kernel sources. When looking at the illumos DRM fork I can see that a lot of X11 code seems to have wandered into the Kernel. And not many files are created by the same people. I am not surprised that this has gotten messy. The illumos kernel docs talk about multiple cases where Data can be accessed and different needs for locking with them. I assume the Linux kernel has similar cases, hence at least mentioning what locks the driver needs to do and which the DRM API does needs to be documented.

Rust in the illumos Kernel

The development model of illumos is different from Linux and thus there are no Rust drivers in upstream illumos yet. But that is to be expected for new things. In our model, we take the time to mature new tech in a fork, and for rust, the Oxide fork has taken that role. In there, we have several drivers for the Oxide Networking stack that are in rust. Based on that some experience could be gained. The current state is, that making things in Rust takes more time compared to C for a trained developer. There is Bindgen which has an overhead to learn and use and there is Language training that people need to become productive. It's one thing to understand the language but becoming productive usually means quite a bit more training on top of that. So far userland tools have proven to be small enough to get to a working result within a reasonable time. OPTE and fast path Networking exist but they still need an integration into the MAC network framework. So more work needs to happen on that front. Smaller drivers are also a possibility to do I am currently unaware of somebody that had an interest though.

The lack of Systems package manager support in rust

Ever since npm started the packaging ecosystem has changed drastically in focus. Where package managers originally installed Software as a System they now shifted to install software on different Systems in the same way. This also changed how responsibilities are handled and how people now develop software. Distributions have become obsolete and are not of interest to people. And that leads to a couple of interesting issues. Because at the end of the day, you need a distribution to start using a Computer. And people that make distributions also need to make some income for that work. But software developers now only need to focus on their software for things to work. Compiling from source has become trivial. But only if you follow the software developer's workflow and know the tools. For people needing to read themselves into how cargo works, some quirks make sense for software developer workflows but are a hindrance for system development workflows. Keep in mind these are different requirements than the ones the kernel needs. Systems Distributors usually do the following:

• Download the sources and make an archive with all the patches they want to bring
• patch the sources from the patch files
• build the binaries
• pack them into an archive for distribution (depends on the package manager)

Several of cargo's features are now counterintuitive and Are the ones I find people criticising. Cargo wants to secure and check that the vendor folder has not been modified. There is no central vendor folder. Rust software can easily have upwards of 100 dependencies and micro dependencies. So if people want audit software it becomes a lot of work. I don't mind. I am long enough in this industry that I have lived through the Java dependency problems on Linux systems. Cargo improves upon that situation. Several other OS's believe that there needs to be a clear differentiation between system and Third-party software. And I agree with that. The Debian approach of putting everything into one system and only having one version of each dependency is not feasible for a huge international community of people that develop together but never meet. Most of the time the devs do not talk to each other at all. I am personally of the opinion, that most of rust builds and their tier system works. And I am happy to rely on that and not just my tools. As a side note. None of this topic requires Harsh words. Systems packagers and Software developers (especially the folks in Debian and traditional Linux distros) have very different ways of thinking and cargo is not a tool for system packagers. It would be nice if it grew some support for that but that does not require harsh words. System source repos like illumos-gate can easily vendor and produce binaries with a small list of dependencies to deliver the binaries via a Package manager. The tools work.

Missing support for shared libraries

A feature not wanted by Software developers, developing for multiple platforms. For systems packagers, this is a required feature. Shared libraries delimit the boundary between two responsibilities. And if those people coordinate then that works well. It becomes a system. There are limits to where this can happen. So I don't know what the perfect solution is. If shared libraries are needed at all or if that feature can fade out. But it is worth a try to build systems and to give people the possibility to do so. So I would wish Rust and Cargo gained shared library support so that we can build such componentized systems easily.

An invite

With all this said I would love to have some more rust folks in the illumos community. And I know this has been expressed by others as well. Userland tools are easy to make in Rust and I for one would love to have people help me with the new Installer and with the package Forge We have gained rust crates for our unique API's such as libcontract Our new image builder for ISO's is in rust image-builder and we are always looking for driver developers. Check out the illumos for all repos Including a config manager. Want to write complete Wifi kernel parts? A small serial Adapter that you have lying around? Want to integrate with an existing Kernel without rewriting it? If anything of that makes you want to head over to https://illumos.org/books/wdd/preface.html#preface and https://illumos.org/books/dev/ or Simply just interests you. Then we would love to have your contribution.

Hope to talk to some folks on Socials and email

-- Toasty

Last week when I wanted to plan the stream and code projects I am interested in I realized, I am already doing this for 1 year!!!! Woot. Actually one year and one month according to twitch but close enough.

Since I am not quite happy about how streaming is going It's a good time to make some changes :) So first of all what is it that I wanted from streaming. Originally I wanted to try it out and see what I can do with it. When you can put in a lot of work into that it works quite well but now that I have a part-time Job it got less priority than before. And now that I got some statistics I can also make some observations on what people like and what actually is worth the effort of making. And when I look at my Youtube statistics of the vods it's very clear what is going on.

So some learnings from those statistics:

• My stream is to early :) According to twitch the Number of viewers on the English language peaks at 20:00 and thats when I stop or have already finished. So if I want to reach more viewers I definetly need to change times.
• Youtube access is mostly from the algorithm and they do not like the long form stream VOD's at all. I think I even got delisted for the last one. However the short demo's and sneak peeks do very well.
• Activitypub in Rust is a hot google search topic :)
• Tutorials do well on youtube. So maybe I actually take some of my learnings and make som tutorials for people.
• During events it's easy to get a couple of people to drop by and have some event fun.
• SolARM streaming does well. Although I really need a Raspberry PI4 for that. Or start to bringup another Single board computer with an ARM chip.

More important for me however is: What are the types of things I like to do with Streaming and Youtube.

• Collaborate and talk to people while coding
• Share usefull information with people
• Share my progress on my projects and generally talks about the Projects.

Looking through the community of people that I follow I can see that a lot of people also still use blog posts, as opposed to Video or Audio. But I like Audio and Video. So I'll see how I can use that to make some devlogs. However I want to use streaming differently than I am using it now. Currently I have a fixed Schedule and try to work on one topic to appease the algorithm. This is however not my preffered style of working as I like having multiple projects at once and switching between them when I get inspired to do so or when my thoughts dwell on it. Thus I will be reducing the streams to special event or purpose streams on topics of interest maybe mostly on topics I want to explore and document but not actaully start a complete project. It also allows me to talk about things people find too fringe for conferences. Maybe I'll find some people that want to stream some gaming sessions but that will probably mostly be in Swiss German as that is my native language. So even for my German speaking audience that will be a challenge to understand. But if I am curious if people would like to have some Swiss gaming content.

So to summarize:

• No more fixed stream schedule
• Dedicated content for videos (thus, start less projects hopefully)
• More vlogs/blogs
• More project schowcases
• Less working on things on stream
• Meh Schwitzerdütsch?

--- Toasty

People may have already noticed, but here it is in long form so I can link this to all Platforms.

tl;dr; the Saturday Stream is moving to Tuesday 16:00 CET - 20:00 CET (thats: 07:00 PT or 10:00 ET) due to more Scheduling conflicts

Since I moved back to Switzerland end of December the Stream got a bit more quiet and I needed to reschedule things. As I have changed both location and Timezone to CET it also dropped people. Since now the Discovery on Twitch is based on CET and not any of the US times that makes a lot of sense So I looked into my schedule and noticed it was now at a very inconvene time for me anyway. And since the Stream is not bound to that time I decided to move it. Since not many people watch it repeatedly it was also a good opportunity to move it now before people make it a fixed Calendar entry.

With this change I am also making a Format change. Previously it was a Stream where I talked and others joined in and maybe asked some questions in Chat. I want to strengthen the Join in aspect a bit more. Thus I will be using my Discord to host a Room for people to come ind and chat. I want this to be more like Twitter spaces than Twitch but will be using Twitch as Broadcasting. On Screen, I'll be looking at a couple of smaller things on stream like Learning Blender or looking things up or whetever is fun at the time. I wanted to depart more from that aproach since I am already developing things outside of the Stream and I have a different style of working that does not exactly fit into that format. So for small things and tutorials etc. its a nice format but for the forge and ARM work I am doing now it is a bad fit. I need to have a focus on stream and not be in an exploratory phase.

For next stream I will be working in Blender. I have a project that I want to make and this gives me a slice of time to look at something like Blender next to all the things going on. The Project I want to try is to try use Blender as a CAD tool to make a bit of an Amateur Digitalisation of one of the Houses my Mother designed the plans for. (My Mother is a Trained Architect). This House currently belongs to my Stepdad and will go up for sale sometime mid this Year as he is getting to old to finish it. Blender has a nice Constraint based toolkit called Archipack Which allows one to make fast and prety beautifull Visualisations.

Hope you all wil join the Hangout

--- Toasty

Hello everyone. So I recently had the desire to make a new Blog post since I now write with helix but hugo did not like me.

So I did what all time conscious people do, I redid my blog from scratch...

As I want to get finally more into making Webdev stuff i decided to give one of the new server based frameworks a try. So I chose SvelteKit to have to possibility to later add nice features and portfolio and other parts to the site. I have copied all my blog posts and formatted them in the new svelte markdown extensions MDsvex The theme is still experimental so feedback is welcome. But I already like that I can include svelte components and render them like this:

[Note: Interactive component would go here in the original Svelte version]

So when I make a fancy code highlighter I can include it directly into my blog posts. Also I can see to add a slides page to my system to display the talks I have given before.

So for now enjoy this little update and more to come soon :)

--- Toasty

Preamble

Welcome to my first devlog. In the Tech sector Public speaking has always been a big part of how we share knowledge and communicate. I personally have talked to people and held some talks but I never really got started with blogging. Although there are multiple attempts, all of them ended with me not liking the format or not wanting to spend the time needed for it to have a good purpose. Recently I got more into Indie game development and the practices in that community. One of which is, that the Game you make in your free time is the fun you have making it. So it's less about the final product and more about the process. The same is true for my OpenSource work. I worked many times on projects for a long time just to realize I do not like the Language (C++) or that in the end it will be better to make another project. And everytime I do that without writing about the process I bury the knowledge about the things I learnt in the code. That is not useful for me nor others. I decided to just write some things I find important about the work of the week. So without further ado here is my first Devlog. Leave me some comments on my Social media or via mail. Hope you like it.

OpenIndiana

Cloney

Starting with a bit of the boring but necessary. This week I made a change to Cloney, the OpenIndiana script helper to copy the downloaded package sources to the build directory. To do that it uses symlinks but several packages like golang 1.18 are using file detection to check the type of file during build. Assembler embedding is the one function that got added in 1.18 specifically. So the build fails, because the symlinks are not followed. The simple fix was to switch to hardlinks but now some other tools require symlinks.... So I will be introduce CLONEY_MODE variable this week, so we can easily switch the build between symlink, hardlinks and recursive copy. For now we have Golang 1.18 packaged an available. It is now the default when installing the golang meta-package.

(Automated) Installer for x86

In more interesting news I have started work on the installer part of the system install and configuration utilities. All the utilities and supporting libraries can be found on GitHub Design wise I made a couple of decisions that can be useful later. All main plumbing and instruction handling is built as libraries. We can use those to either easily build tools to configure and install systems or other use cases we can come up with. In any case it is a comprehensive gathering of configuration and setup tasks. I don't know yet how most people will want to use the automated installer but that is decidable at a later stage. For now the usecase i think will be most useful one, is that people can freely define a step by step instruction file. This file together with the templates of files to be rendered or copied in place make up an installation bundle. One can then use git or a webserver to store that install bundle and the tar archive of the image to be installed. I later want to support imgapi from smartos as storage aswell which is why I started with the libimgapi crate in the installer workspace. At the moment it can only parse the manifests returned by https://images.smartos.org but that will be enough for the start. I do at the moment liberaly clone code from @jclulows image builder. Mostly because the steps he used to build the image also fit the installer use-case. Installed imaged are after all also only images in the illumos ips world.

Aurora OpenCloud

A friend of mine has shared recently the garage S3 Server with me. And based on that together with some services like nextcloud and vyos I think I have the start of a capable cloud backplane and some initial services people like. ownClouds ocis is also nice to have as it allows providers to provide within their ecosystem.

As this cloud software will be heavily based on the cli I had a basic idea on how that should be seperated. The workflow I am aming for is configure -> commit -> deploy with that one can easily manage configuration versions but also use the ClockOps workflows. As it's simply a commit without needing a review. I want to wrap that into 3 CLI's

• cloudcfg (or cldcfg) which will handle the writing of configurations and applying them to the cloud. The config files will live in the cloud and modified by a GRPC API. I don't know yet how I want to handle the storage. But most things will have Postgres as database backend for the Configuration that is currently active. I want something simple though. Nothing that computes state or does more things than the operator explicitly says.
• cloudadm (or cldadm) will be responsible to administer and maintain resources. Say reboot a service that you are managing inside a tenant or switching of a machine.
• cloudsh (or cldsh) will be the main shell to read data from the cloud and process it. I want to make it based on nushell. This will allows admins to do fancy data analysis on their management VM's or local computers without needing to fall back to text parsing. Monitored alerts and data can be printed to the data channel by plugins and the builtin commands and filters from nushell do the heavy filter lifting making development easier and giving the most flexibility one can get from any tool that outputs data.

Indiedev

In personal news, as I am getting rid of all my Maker tools, I limited myself to two Hobbies. Working on illumos and Indie game development. I will be doing this with two friends. So today we sat down for a Virtual Coffee and Brainstormed what we would like to do.

We ended up with the following synthesized list:

• Sci-fi Ancient Greece / Gothic styles (to starts)
• Vermintidelike mass enemy action
• Buildup of Cities and Trade
• Different worlds accessible via Portals
• Snappy Battle system
• Fancy sound with a wild mix of Genres (My friends want to play with their synthezisers and Instruments and see what they can make)
• Modding support

More on this will come in the next weeks when we see how this ideas develop. For now it gives me a very elegant excuse to have a look into Godot 4's Multiplayer support.

Hope you liked this devlog and leave me note on the Socials what you like to read up more in details.

So long -Toasty

Hello everyone! As I haven't written anything in quite a while, it became apparent that I either have to switch my site to something more usefull or to start writing again.

As I am always doing something but never talking about it, I figured this is as good an opportunity to start writing as any other. And I actually would like to do that.

So to grab that opportunity and have some fun, I decided to restart my blog and make it basically my status update site. Write what software I am writing, why I am writing it and what I am thinking about things.

For one this gives some insight for others that do packaging and development work. And on the other side I think and design quite some things that I am passionate about and would like to share more. But since writing themed articles takes a lot of time I want this to be more freestyle.

If you like this more freestyle kind of content enjoy the reading :) And let me know on the Socials what you guys think.