We have moved to a new Sailfish OS Forum. Please start new discussions there.
1 | initial version | posted 2016-06-08 01:21:32 +0200 |
One of the problems preventing kernel upgrades is that there are binary blobs from the radio layer that restrict kernel versions to run. I an idea on a way around that limitation:
Build a stripped down kernel that follows the binary blob restrictions, then use that as a hypervisor for another kernel that actually runs the real OS. So Sailfish OS will run in a virtual machine using its own unrestricted kernel, under a hypervisor that runs the binary blobs with all its restrictions.
2 | No.2 Revision |
One As I understand it, one of the problems preventing kernel upgrades is that there are binary blobs from the radio layer that restrict kernel versions to run. I an idea on a way around that limitation:
Build a stripped down kernel that follows the binary blob restrictions, then use that as a hypervisor for another kernel that actually runs the real OS. So Sailfish OS will run in a virtual machine using its own unrestricted kernel, under a hypervisor that runs the binary blobs with all its restrictions.
3 | No.3 Revision |
As I understand it, one of the problems preventing kernel upgrades is that there are binary blobs from for the radio hardware layer that restrict kernel versions to run. I an idea on a way around that limitation:
Build a stripped down kernel that follows the binary blob restrictions, then use that as a hypervisor for another kernel that actually runs the real OS. So Sailfish OS will run in a virtual machine using its own unrestricted kernel, under a hypervisor that runs the binary blobs with all its restrictions.
4 | No.4 Revision |
As I understand it, one of the problems preventing kernel upgrades is that there are binary blobs for the hardware layer that restrict kernel versions to run. I have an idea on for a way around that limitation:
Build a stripped down kernel that follows the binary blob restrictions, then use that as a hypervisor for another kernel that actually runs the real OS. So Sailfish OS will run in a virtual machine using its own unrestricted kernel, under a hypervisor that runs the binary blobs with all its restrictions.
5 | No.5 Revision |
As I understand it, one of the problems preventing kernel upgrades is that there are binary blobs for the hardware layer that restrict what kernel versions to run. I have an idea for a way around that limitation:
Build a stripped down kernel that follows the binary blob restrictions, then use that as a hypervisor for another kernel that actually runs the real OS. So Sailfish OS will run in a virtual machine using its own unrestricted kernel, under a hypervisor that runs the binary blobs with all its restrictions.
6 | No.6 Revision |
As I understand it, one of the problems preventing kernel upgrades is that there are binary blobs for the hardware layer that restrict what kernel versions to run. I have an idea for a way around that limitation:
Build a stripped down kernel that follows the binary blob restrictions, then use that as a hypervisor for another kernel that actually runs the real OS. So Sailfish OS will run in a virtual machine using its own unrestricted kernel, under a hypervisor that runs the binary blobs with all its restrictions.
Edit: The core issue regarding this scheme is performance impact. This is hard to predict, modern virtualization can have almost no performance impact; it depends heavily on what hardware support for virtualization one can expect now and in the future. We might be helped by the fact that only a single specific OS will ever run in the VM, so both guest OS and the Hypervisor may be specialized for each other.
7 | No.7 Revision |
As I understand it, one of the problems preventing kernel upgrades is that there are binary blobs for the hardware layer that restrict what kernel versions to run. I have an idea for a way around that limitation:
Build a stripped down kernel that follows the binary blob restrictions, then use that as a hypervisor for another kernel that actually runs the real OS. So Sailfish OS will run in a virtual machine using its own unrestricted kernel, under a hypervisor that runs the binary blobs with all its restrictions.
Edit: The core issue regarding this scheme is performance impact. This is hard to predict, modern virtualization can have almost no performance impact; it depends heavily on what hardware support for virtualization one can expect now and in the future. We might be helped by the fact that only a single specific OS will ever run in the VM, so both guest OS and the Hypervisor may be specialized for each other.
8 | No.8 Revision |
As I understand it, one of the problems preventing kernel upgrades is that there are binary blobs for the hardware layer that restrict what kernel versions to run. I have an idea for a way around that limitation:
Build a stripped down kernel that follows the binary blob restrictions, then use that as a hypervisor for another kernel that actually runs the real OS. So Sailfish OS will run in a virtual machine using its own unrestricted kernel, under a hypervisor that runs the binary blobs with all its restrictions.
Edit: The core issue regarding this scheme is performance impact. This is hard to predict, modern virtualization can have almost no performance impact; it depends heavily on what hardware support for virtualization one can expect now and in the future. future (virtualization support in ARM has improved dramatically the last few generations). We might also be helped by the fact that only a single specific OS will ever run in the VM, so both guest OS and the Hypervisor may be specialized for each other.
Edit2: A possible alternative is to turn it around. Make the hypervisor the main OS, and make sure it performs HW pass-through to the guest. Then put the binary blobs in the guest, along with a minimal blob-compatible kernel and let the guest serve the blob-liberated hypervisor.