On 01/12/2016 09:56 PM, Jookia wrote:
On Tue, Jan 12, 2016 at 04:32:20PM +0100, Reto Buerki wrote:
- Distributed Genode
Having a complete Genode system running in one Muen subject does not bring much benefit as it does not leverage the isolation properties provided by the SK. Therefore we intend to add support for executing multiple Genode subjects as a distributed environment while providing inter-subject communication channels. In order for the Genode instances to exchange data, the concept of so-called Proxy components as suggested by the Genode developers will be applied.
The proxy concept uses two components: a server and a client. Both of them implement a specific Genode service interface and communicate using a Virual Hardware (VHW) abstraction layer to create a bridge between the separated components. The following diagram illustrates the concept for the Log service:
log() -> Proxy:Client -> | VHW | -> Proxy:Server -> Log_Server
For Muen, we will implement the VHW functionality using shared memory channels and events.
This seems like a really interesting idea, and something I've thought about for a while. Could you elaborate a little more on what you think the VHW functionality might entail? Is it specific to the kernel?
VHW is the abstract term for the transport medium and might be specific to the kernel. On Muen the medium is shared memory in combination with events. One can think of it as a virtual device in the sense that state is visible in memory (analogous to device MMIO) and IRQs are used to signal the availability of new state.
Whether VHW should use a uniform interface needs to be seen, maybe it will be easier to just implement different proxy components per use case.
I think we will start off with a simple log client where the write() implementation stores the log buffer contents in shared memory and informs the server via an event about new data. The server will be a native Muen component running as separate subject.
I somewhat imagine a Genode system running over a network with different kernels per-device, so in that scenario it'd be a network VHW.
In the network VHW case the implementation might not be kernel specific, the proxy components would just reuse existing networking facilities.
On another note, this is some really great work being done, I'm excited to see what comes of it- Perhaps the next Qubes OS for x86_64.
Thanks, I'm glad you like our work.
Regards, - reto