Relatively common in more powerful embedded systems. See for example https://www.openampproject.org/ which is a framework for running multiple cores of Linux, baremtal, or an RTOS together.
OpenAMP focuses on RTOS running on "subordinate" coprocessors.
This is more of a good old classic partitioning, which was rare outside of hardware with special support for it.
Most RTOS + non-RTOS combinations use RTOS doubling as hypervisor, with RT tasks running at guaranteed timeframes and non-RTOS guest running in more relaxed form.
You can also use it in a "SMP" processor. For example I use it on Zynqs which are dual or quad ARMs symmetrical ARM SoCs. Linux or the bare code can be the master or subordinate.
IIRC, colinux is similar to user mode Linux, which boots a kernel in userland. That is, the kernel runs under windows as an application rather than alongside it.
Unlike in other Linux virtualization solutions such as User Mode Linux (or the forementioned VMware), special driver software on the host operating system is used to execute the coLinux kernel in a privileged mode (known as ring 0 or supervisor mode).
By constantly switching the machine's state between the host OS state and and the coLinux kernel state, coLinux is given full control of the physical machine's MMU (i.e, paging and protection) in its own specially allocated address space, and is able to act just like a native kernel, achieving almost the same performance and functionality that can be expected from a regular Linux which could have ran on the same machine standalone.
So my understanding is that it's a Windows driver which contains a full Linux kernel and does some (scary sounding!) time sharing with the Windows kernel running at the same CPL.
I did not remember that from when I used to use colinux.
The colinux home page also says:
To cooperatively share hardware with the host operating system, coLinux does not access I/O devices directly. Instead, it interfaces with emulated devices provided by the coLinux drivers in the host OS. For example, a regular file in Windows can be used as a block device in coLinux. All real hardware interrupts are transparently forwarded to the host OS, so this way the host OS's control of the real hardware is not being disturbed and thus it continues to run smoothly.
So just like UML, colinux hooks int 80h (or sysenter) and forwards the request to windows. Thus while it may make use of direct access to the MMU, most devices iirc are virtualized.
HP printers are similar. They run Linux on two cores and an RTOS on the other.
Relatively common in more powerful embedded systems. See for example https://www.openampproject.org/ which is a framework for running multiple cores of Linux, baremtal, or an RTOS together.
OpenAMP focuses on RTOS running on "subordinate" coprocessors.
This is more of a good old classic partitioning, which was rare outside of hardware with special support for it.
Most RTOS + non-RTOS combinations use RTOS doubling as hypervisor, with RT tasks running at guaranteed timeframes and non-RTOS guest running in more relaxed form.
You can also use it in a "SMP" processor. For example I use it on Zynqs which are dual or quad ARMs symmetrical ARM SoCs. Linux or the bare code can be the master or subordinate.
IIRC, colinux is similar to user mode Linux, which boots a kernel in userland. That is, the kernel runs under windows as an application rather than alongside it.
It says on the web page I linked that:
Unlike in other Linux virtualization solutions such as User Mode Linux (or the forementioned VMware), special driver software on the host operating system is used to execute the coLinux kernel in a privileged mode (known as ring 0 or supervisor mode).
By constantly switching the machine's state between the host OS state and and the coLinux kernel state, coLinux is given full control of the physical machine's MMU (i.e, paging and protection) in its own specially allocated address space, and is able to act just like a native kernel, achieving almost the same performance and functionality that can be expected from a regular Linux which could have ran on the same machine standalone.
So my understanding is that it's a Windows driver which contains a full Linux kernel and does some (scary sounding!) time sharing with the Windows kernel running at the same CPL.
I did not remember that from when I used to use colinux.
The colinux home page also says:
To cooperatively share hardware with the host operating system, coLinux does not access I/O devices directly. Instead, it interfaces with emulated devices provided by the coLinux drivers in the host OS. For example, a regular file in Windows can be used as a block device in coLinux. All real hardware interrupts are transparently forwarded to the host OS, so this way the host OS's control of the real hardware is not being disturbed and thus it continues to run smoothly.
So just like UML, colinux hooks int 80h (or sysenter) and forwards the request to windows. Thus while it may make use of direct access to the MMU, most devices iirc are virtualized.
This was underrated!