VDiSK: Virtual Distributed Streaming Kernel

• VDiSK is a custom runtime OS layer within CHAMP that orchestrates modular AI pipelines by managing USB-attached cartridges.
• It combines low-level kernel USB management with a high-level user-space daemon to efficiently register capabilities and route data streams.
• VDiSK supports hot-swapping and runtime reconfiguration while providing secure biometric template storage via homomorphic encryption.

Searching arXiv for CHAMP/VDiSK and prior VDiSK references. VDiSK, defined in CHAMP as the Virtual Distributed Streaming Kernel, is a lightweight operating system designed for orchestrating modular AI pipelines in a hot-swappable edge-computing platform for biometric and related perception workloads. Within CHAMP, it runs on the Main Compute Module—an NVIDIA Jetson AGX Orin running lightweight Linux—and serves as the orchestration layer between USB-attached “capability cartridges” and a database/storage cartridge, handling discovery, capability registration, routing, pipeline construction, hot-swap reconfiguration, and privacy-preserving biometric template storage (Brogan et al., 23 Jul 2025).

1. Definition and position within CHAMP

VDiSK is not presented as a monolithic general-purpose operating system. In CHAMP it is characterized as a custom runtime/OS layer whose role is analogous to “an inference server combined with a router”: it recognizes when cartridges are added or removed, queries their capabilities, and manages a message-passing interface over the CHAMP bus so that data is handed off between cartridges efficiently (Brogan et al., 23 Jul 2025).

Its physical placement is central to the CHAMP architecture. The Orin-based Main Compute Module is directly connected to a multi-drop USB 3.1 Gen1 bus backplane, and each capability cartridge appears as a USB-attached device on that bus. A database/storage cartridge is attached on the same bus and can store encrypted biometric templates. VDiSK therefore occupies the middle layer between hardware modules that provide specific capabilities and storage modules that define the matching calculation for the template type they store. This design makes VDiSK the software “glue” that turns a collection of independent cartridges into a coherent biometric or perception pipeline (Brogan et al., 23 Jul 2025).

A common misconception is to treat VDiSK as merely a device manager. The CHAMP description is broader: VDiSK knows which cartridges are present, determines how they connect into a processing pipeline, routes data between them, handles insertions and removals, and manages secure biometric template storage and homomorphic encryption within the database/storage cartridge. This suggests that its functional scope spans orchestration, transport semantics, and selected security services rather than simple enumeration alone (Brogan et al., 23 Jul 2025).

2. Software architecture and data model

The CHAMP-specific VDiSK fork is implemented as “a set of Linux daemons and kernel modules.” One kernel driver manages the physical bus by detecting devices and reading from and writing to bus addresses, while a user-space daemon performs high-level orchestration, including capability registration, data routing, and health monitoring (Brogan et al., 23 Jul 2025).

VDiSK uses a publish/subscribe model for data exchange between cartridges, described as similar to ROS topics but optimized for high-throughput streaming of imagery and vectors. Upon insertion, each cartridge registers with VDiSK and advertises the type of data it consumes and produces—for example, taking an image frame and outputting bounding boxes and labels. VDiSK then links cartridge outputs to downstream inputs according to either the physical order of cartridges or a user-specified sequence (Brogan et al., 23 Jul 2025).

The system abstracts both continuous and sporadic interactions as streams of messages. Cartridges may operate in streaming mode, such as continuous video-frame processing, or in request-response mode, such as discrete database lookups. VDiSK treats both uniformly as message streams. On the bus, all cartridges conform to a common protocol for data exchange, including framing for messages, sequence numbers for image frames, partitioning for large payloads, and metadata describing type and size for inference results. Flow control is distributed: if a cartridge’s processing time is slower than the input rate, its bus controller can signal upstream modules or the main controller to throttle the flow and prevent overload (Brogan et al., 23 Jul 2025).

The design is therefore layered. The kernel-level component is responsible for USB-level queues and low-level I/O, while the user-space orchestration daemon maintains the cartridge registry, builds the pipeline graph, maps logical streams to physical endpoints, and manages backpressure and health state. The paper does not provide an explicit API or interface definition language, and it does not describe a complex scheduler such as round robin or work stealing. Instead, it specifies a capability ID, input/output typing, and a message framing protocol as the operative interface (Brogan et al., 23 Jul 2025).

3. Runtime reconfiguration and hot-swapping

Runtime reconfiguration is a defining property of VDiSK in CHAMP. At boot, VDiSK enumerates cartridges already present, loads the necessary support libraries or drivers for each cartridge type, and builds an initial pipeline graph. During operation, the main module monitors the bus for connection and removal events using USB’s standardized device detection and Zeroconf/mDNS (Brogan et al., 23 Jul 2025).

When a new cartridge is inserted, VDiSK pauses the pipeline for “a few milliseconds to a second,” addresses the new cartridge, and initiates a handshake. The cartridge reports a capability ID and data format, after which VDiSK integrates it into the pipeline at the correct position. If the cartridge is physically inserted in slot 2 of 4, it becomes the second stage in the pipeline; more generally, outputs of stage $i$ are rewired to stage $i+1$. On removal, VDiSK either bridges the gap if the pipeline can continue without that function or pauses the pipeline and notifies the operator that a capability is missing (Brogan et al., 23 Jul 2025).

To maintain stable operation during hot-swap events, the CHAMP fork of VDiSK buffers incoming data and reconfigures routing. If a module is removed, its upstream neighbor is instructed to pause or redirect output, while its downstream neighbor either receives a default pass-through or triggers an alert for operator intervention. This makes the hot-swap mechanism operationally robust, but not invisible: the paper explicitly reports that further refinement is needed to make it “truly seamless” (Brogan et al., 23 Jul 2025).

Plug-and-play behavior is primarily physical rather than declarative. The operator inserts cartridges in the desired order, and the system auto-configures accordingly. A fork of the ComfyUI workflow editor is used so that operators can see which cartridges are present and active, and can manually reorder or toggle certain pipelines if needed, but the primary mode of configuration is physical insertion followed by automatic registration and automatic pipeline update. This design choice is explicitly tied to a field-use requirement: CHAMP is intended to be usable by non-technical personnel (Brogan et al., 23 Jul 2025).

4. Security and biometric template privacy

The security functions attributed to VDiSK in CHAMP are centered on cryptographically secured biometric datasets and template privacy. The key mechanism identified in the paper is homomorphic encryption for biometric templates stored in the database/storage cartridge. In the canonical face-processing pipeline described by the authors, identified faces are passed to a database cartridge that checks them against a biometric database, which can be encrypted via VDiSK’s built-in homomorphic encryption for templates (Brogan et al., 23 Jul 2025).

The storage model is modular. Biometrics such as face embeddings produced by a Face Recognition cartridge are stored in the database cartridge, and that cartridge also defines the necessary matching calculation for the template type it stores. CHAMP attributes these homomorphic-encryption capabilities to prior VDiSK work by Brogan et al. (2023), but the CHAMP paper does not restate the underlying scheme, its equations, or its implementation details [250