Hardware Abstraction: The Virtual File System (VFS)
A fundamental requirement of edge-native deployments is immense portability. Edge environments frequently operate outside the norms of standard commercial clouds—they utilize entirely custom kernels, experimental Real-Time Operating Systems (RTOS) like FreeRTOS or VxWorks, and extremely obscure physical storage controller architectures. PomaiDB must operate flawlessly, and synchronously, across them all without modification to its core logical execution loops.
PomaiDB achieves this hardware agnosticism via a robust, highly extensible Virtual File System (VFS) layer.
1. Complete Quarantine from POSIX Dependencies
Typical UNIX databases (and even standard embedded datastores like SQLite) directly inject POSIX system calls (such as <unistd.h>, <fcntl.h>, pwrite(), and mmap()) throughout their operational B-Tree logic. The moment developers compile that database for an aerospace RTOS lacking those exact headers, compilation completely fails.
- PomaiDB absolutely forbids OS-specific system libraries inside the core logic (
db/,membranes/,query/). - The system storage layer multiplexing, multi-threading construction loops, and clock synchronization algorithms are universally routed through abstract
pomai::Envpointers.
2. Custom Environment Demonstrations (InMemory & Embedded)
PomaiDB intrinsically supplies an InMemoryEnv backend utilized primarily within the internal testing suite to safely execute millions of assertions instantaneously without eroding the physical NVMe disks. This identical structure demonstrates exactly how an enterprise engineers bare-metal abstractions.
// Example: Injecting completely custom hardware storage logic into PomaiDB via VFS
#include "pomai/pomai.h"
#include "pomai/env.h"
#include <iostream>
class CustomAerospaceEnv : public pomai::Env {
public:
// Overriding the clock mechanism bypassing standard kernel time loops
uint64_t NowMicros() override {
return CustomHardwareTimer::ReadMonotonicTicks() * 1000;
}
// Overriding physical file generation logic to target proprietary flash EEPROM
pomai::Status NewWritableFile(const std::string& fname,
pomai::WritableFile** result) override {
// Instantiate a custom class wrapping the hardware's SPI protocol
*result = new AerospaceSPIWritableFile(fname);
return pomai::Status::OK();
}
// Manage threads bypassing standard pthreads
void StartThread(void (*function)(void*), void* arg) override {
VxWorksNativeScheduler::Spawn(function, arg);
}
};
int main() {
// 1. Instantiate the absolutely custom Hardware Environment
CustomAerospaceEnv drone_hardware_env;
// 2. Configure the Engine to explicitly utilize the custom VFS
// instead of the default POSIX fallback.
pomai::DBOptions opt;
opt.env = &drone_hardware_env; // Complete abstraction injection!
opt.path = "/virtual_volume/telemetry";
opt.dim = 64;
std::unique_ptr<pomai::DB> secure_db;
auto status = pomai::DB::Open(opt, &secure_db);
if (status.ok()) {
std::cout << "[SUCCESS] Engine bounded directly to proprietary hardware abstractions.\n";
}
return 0;
}Env to ascertain if the hardware supports logical Memory Mapping Unit (MMU) functionality via the FileMapping interface. If Memory Mapping is unsupported by the embedded chip, PomaiDB automatically degrades safely, switching its internal read-paths from zero-copy pointer arithmetic over to standard buffered block loading automatically.