Originating from this comment, I have a proposal to implement some kind of mechanism to allow non-native binaries to be executed on Haiku.
Non-native binaries here are defined as any executable binary file that runtime_loader
doesn’t accept. This includes binaries for different architectures or even different operating systems.
The most apparent use of this is allowing x86 (or more importantly, x86_gcc2) binaries on x86_64 Haiku (HoH64). In the far future the use can be extended to allowing x86_64 apps to run on different architectures through the use of a JIT compiler or running some Linux binaries to ease the process of cross-compiling some software to Haiku.
I can think of two possible implementations:
- Kernel driver: Syscalls originating from teams running non-native binaries are dispatched to this kernel driver. It then translates into calls of the corresponding Haiku subsystems.
-
runtime_loader
add-on: Certain binaries can be registered as add-ons forruntime_loader
. Whenruntime_loader
fails, it calls on these binaries by registration order, until all fail or one handler succeeds. Syscall translation should be done by the handler binary, and all syscalls dispatched by the team is native for the architecture.
The kernel driver method gives the emulator more access to kernel resources and allows better emulation in some cases where platform-specific system calls involve handling low-level information stored in the kernel, while the userspace add-on method is simpler and more stable but kernel interaction is limited to syscalls only.
The advantage of both methods is that the support does not require using an entirely different kernel version of Haiku, and the drivers or add-ons can be distributed through HaikuDepot like any other app.