Adding new applications to GHAF

[dmitry-erin]

Currently the way of adding a new application to GHAF is not clear. (at least I have not found any instructions and rules). What the app should be on GHAF: module, package or smth else. As an example I took a look at the GALA app. The GALA app already added to the GHAF. Is the way it was added right/suitable for all?

[juliuskoskela]

I think this question is being worked on right now.

Some related discussion under https://github.com/tiiuae/ghaf/issues/141

I have proposed we start working on related documentation as we gain experience from the different integrations being done right now.

[vilvo]

Thanks for asking, here's a quick sketch of integration approach with architecture evolution that considers other constraints beyond adding apps. As it is a bit of a boxology and the challenges are in the details, I'd be happy to address questions and concerns related to the approach. I try to address some most obvious below the sketch.

1st phase reflects the current stage. Apps and the whole GUI stack are just added to host. This blocks the minimal host development - https://github.com/tiiuae/ghaf/pull/140 - as we cannot have both minimal and graphically rich host at the same time. The key point of this stage is to test and demo declarative Ghaf environment with apps and netvm isolation.

2nd phase will introduce cross-domain wayland protocol between appVM isolated wayland applications and the isolated wayland compositor (weston) in GUIVM. @mikatammi is working the enable cross-domain wayland based on the earlier work. We had this working at demo prototype level in the Ghaf-predecessor on iMX8 reference device. Another feature that will be introduced here is the GPU passthrough (GPU hardware and native driver owned by the GUIVM) - I left the GPU passthrough out of the sketch for clarity. This is being enabled with PCI GPU passthrough (works already) and platform GPU (requires BPMP integration by @juliuskoskela). You in app development can take an optional sub development phase here and keep the GUI stack (Wayland compositor stack) and the applications within the same GUIVM - at least until we get the cross-domain wayland protocol working properly. Note that this phase also enables the minimal-host usage by @remimimimimi Also, we can still have the vmd server here on host for the keeping the backend access simpler but it will move to admimVM in the next phase.

3rd phase - no changes from appVM perspective but the vmd server is isolated to the adminVM and it will communicate with the host without networking - using shared memory messaging. This setup will likely contain many other VMs, including other appVMs, that are getting more minimal to optimize the space and for security as well. From appVM definition perspective, we can run both NixOS-based appVMs and VMs based on other Linux distros (like Ubuntu) and even Windows (which is possible already now - https://tiiuae.github.io/ghaf/research/run_win_vm.html). Application backup and restore functionalities will also be piloted with applications at this phase.

Finally - adding applications is both straight-forward (just add to host for now to test) and will require application environment refactoring. I propose you get familiar with microvm.nix based appVM declarations for more optimized appVMs. In addition, we will want Ubuntu-based guestVMs - either similar to Windows VM guides https://tiiuae.github.io/ghaf/research/run_win_vm.html or using nix-based declarations to include them into the ghaf system images. So starting with Ubuntu-based appVMs that can talk cross-domain Wayland is also an option.