POD vs CONTAINERS vs VM
I received this video presentation from the IBM newsletter and I like to share with you.
In this video, Red Hat developer advocate, Cedric, explains the differences between containers and pods, providing example scenarios, and steps for getting started with Kubernetes on your local server or laptop.
IMHO, the most interesting part is summarized in this picture which shows the main difference in usage from virtual machine and containers
Therefore the first guess to using a VM to separate the AOSP image from the supervising OS was a good try.
As we can read in the link above about KVM, also Google feel uncomfortable about kernel fragmentation among various Android version. Therefore, providing a supervising OS that free the Android from a specific version of the kernel but a range of version. We cannot expect that the same system will work effortlessly from 1.0 and 10.0 but a reasonable range like 4.x and 6.x can be a HUGE advancement.
I am quite optimistic that when a functional PoC about this kind of abstraction will be presented, it will receive the attention of Google Android team and probably adopted by them as well.
Now, being back to the separation of the AOSP from the supervising OS, the container model seems the best fit for this goal because the OS (the kernel) stays out of the container. The next question is:
- should the root filesystem shared among the supervising OS and the AOSP container?
It will be nice but the standardisation of a basic filesystem will bring in a lot of effort from 3rd party independent projects like busybox or toybox which does not sound feasible nor a good choice to go, not immediately for sure.
Even this standardisation can not even been necessary among various supervising OS because after all, competition among different implementation is also based on this aspect. After all, who cares?
Fragmentation among root filesystems never be a big issue as long as and as far as some general rules - well established by now - are respected. This also apply about the start-up system (e.g. initd or SysV), the two can be completely separated. However, it would be important that the two would not interfere.
On the long term along the developing line, the supervising OS should be able to initialise all the hardware and load all firmwares properly. Therefore there are different components:
- monolithic kernel with all the drivers embedded
- root filesystem with shell and busybox or toybox
- a set of firmware for the specific hardware
The #2 can be generic and specific for each supervising OS, including the system start-up stuff. About the #3, we are used to have one partition that contains all these firmware specifically selected for each mobile device and there is no reason to change this. About #1, we might decide that a monolithic kernel is not any more the best approach to go with. A generic kernel might be combined with a partition in which will contains all the modules selected for each mobile device. This partition can be contained into the boot image - boot partition itself, not necessary a real partition.
About #3, also an hybrid approach can be used: essential modules in the boot image in order to being able complete the boot and mount the extra kernel modules partition. Why do not embedded some essential modules into the kernel, instead?
It is not just a matter of taste but about hardware fragmentation among the same smartphone family. It is faster to have a build procedure that choose different modules to be included into an image rather than recompiling the kernel image. Imagine to have 6 devices belonging to the same hardware family - this group of device, we might call a hardware platform - the best is that the essential modules are the same and probably the hardware vendors and smartphone producers will move in this direction but we cannot take it as always given.
I wish to ear some opinions about the idea of returning to the kernel modular approach. Also about everything else I wrote, but for this specific topic - which breaks the current default approach - in particular.
Removing the firmware loading and the hardware initialisation from the AOSP allows the AOSP to be containerised on different hardware. Obviously, in those system in which the hardware is missing, e.g. GPS, all the related functions and apps. will fail unless that hardware would not be simulated.
However, the simulation of some hardware sub-system like GPS can be very important to debug the functionalities and apps. also in corner cases which are quite difficult to see in the real-world but possibly can be meaningful for real-life or real-world emergencies or security.