Currently, the kona-host binary shells out to invoke the kona-client binary, rather than executing it in-process. This was done towards the beginning in order to test the kona-preimage API natively in a similar way that the FPVMs use, but there are a few problems:
It contains mappings that are invalid on the native architecture or non fault proof VMs (i.e. zkVMs). This is a poor abstraction for re-use.
On the NativeIO implementation, we have to take a FileDescriptor type, which is bad for reasons described in #553.
The kona-host implementation therefore has to keep the pipe files for the client program alive, in order to guarantee that the pipe remains open for the duration of the asynchronous child process' lifetime.
Instead of doing this, we should change kona-host up so that kona-client runs natively within the process. This will remove the need for the NativeIO entirely in kona-common, and then we can split kona-common into client program utilities and FPVM-specific logic. This should remove the need to solve #553.
Overview
Currently, the
kona-hostbinary shells out to invoke thekona-clientbinary, rather than executing it in-process. This was done towards the beginning in order to test thekona-preimageAPI natively in a similar way that the FPVMs use, but there are a few problems:BasicKernelInterface::write&BasicKernelInterface::readinterfaces take an ownedFileDescriptor, which is inflexible for a few reasons:NativeIOimplementation, we have to take aFileDescriptortype, which is bad for reasons described in #553.kona-hostimplementation therefore has to keep the pipe files for the client program alive, in order to guarantee that the pipe remains open for the duration of the asynchronous child process' lifetime.Instead of doing this, we should change
kona-hostup so thatkona-clientruns natively within the process. This will remove the need for theNativeIOentirely inkona-common, and then we can splitkona-commoninto client program utilities and FPVM-specific logic. This should remove the need to solve #553.