liboni¶
- Source Code
- License
liboni is a C library that implements the ONI API Specification. It is written in C to facilitate cross
platform and cross-language use. It is composed of the following files:
onidefs.h: common definitions
oni.h: core API
onidriver.h: device driver translation layer that must be implemented for a particular host hardware connection and firmware.
ondriverloader.h: private functions used for dynamically loading the hardware driver. This is used internally by the oni.h and can be ignored during both software and driver development.onix.h: ONIX-specific, out of ONI API specification scope, definitions and functions. Can be ignored for projects that do not interact with ONIX hardware.
liboni is a low level library intended for use by high-level language
binding and/or software plugin developers. The only external dependency aside
from the C standard library and dynamic library loading functions is is a
device driver translation layer (onidriver.h, “driver” for short) that
fulfills the requirements of the ONI Host Interconnect Specification. Our API
implementation contains drivers for
RIFFA is a free and open-source FPGA IP core and device driver that allows the ONI communication channels to be implemented using the PCIe bus. ONIX PCIe-based hardware uses RIFFA.
Xillybus is a proprietary FPGA IP cores and free and open source device drivers to allow the communication channels to be implemented using the PCIe bus. The licensing terms for the FPGA core are extremely unclear, although “trial” use is allowed. Use at your own risk.
FTDI USB3.0: Planned
From the API’s perspective, hardware communication abstracted to IO system
calls (open, read, write, etc.) on file descriptors. File
descriptor semantics and behavior are identical to either normal files
(configuration channel) or named pipes (signal, data input, and data output
channels). Importantly, the low-level synchronization, resource allocation,
and logic required to use the hardware communication backend is implicit to
liboni API function calls. Orchestration of the communication backend is
not directly managed by the library user.