The availability of support for various apps and drivers (for various hardware and software) is crucial for the general adoption of any general purpose operating system like Redox OS. Some of us developers are working on improving the core of Redox OS (like the Kernel), which should create a solid base on which high quality native drivers and apps can be created with ease. Some others are working on porting (and adapting) various open source drivers and apps (written for other OSes) such that they can work with Redox OS. This work is super important and helps Redox OS progress forward.
But in the meanwhile, there’s a potential shortcut to enabling wide driver and app support for Redox OS, without having to manually port and adapt drivers to Redox OS. (which can be helpful, both today and in the future). The shortcut, in simple words, is to use our Host machine running Redox OS, to run a Virtual Machine with another OS (Linux/Windows) as the guest, and then cleverly use the drivers and apps that can run on that guest OS to help coverup the missing drivers and apps on Redox OS.
This is not a novel solution, but it is quite clever and ingenious. I’m wondering how this would impact performance, and if stability suffers from going through several layers like this. There’ll be a more detailed post with technical details of the implementation later on, so keep an eye out for that one.
Looks like an interesting project for me to add to my lab, while I look for employment.
It is pretty clever from a techincal poit of view. I do see trouble with large overhead. Spinning up a (minimal) linux/BSD instance just to use one driver or one app will be costly in memory, CPU cycles and drive space. For everything that isn’t native, you’ll get a mini OS running the foreign thing. Better max out the RAM…
Another pitfall is the risk of dwindling native development. Why spend time implementing a native NTFS driver? The Linux NTFS driver VM works wonderfully. Third party apps will have even less incentive to port to Redox. Just use the appropriate VM.
In the end I wonder what the point is of a microkernel OS, written in a safe language, if the driver and application landscape is a Franken-hodgepodge of different OSes with varying levels of safety in a myriad virtual machines.
I know of the chicken and egg problem, but in this case the cure may be worse than the disease.
r_a_trip,
I agree on both fronts.
This is the same dilemma alt-os faces for applications, only this time with drivers. If you support the applications & drivers of a foreign OS, then you do benefit by having access to them. This is valuable, but it is also disruptive to native development and innovation. By reshaping the OS around other operating systems, you loose some creative control as the other operating system boxes you into being compatible with their models.
One of my gripes with the linux kernel is that it relies heavily on blocking (ie calls that are designed to block instead of return strait away). If you want to implement an asynchronous non-blocking API on top of linux, it has to be built on top of the native blocking API. One such implementation is posix AIO…
https://linux.die.net/man/7/aio
However performance of posix AIO on linux is absolute garbage because the kernel doesn’t support AIO and so every “nonblocking” request has to use up a userspace thread. So while your application might be handling asynchronous IO extremely efficiently, POSIX AIO is forced to spawn up threads behind the scenes. This introduces major inefficiencies that not only brings down performance, but also causes memory utilization to shoot up. Cache and TLB misses become significantly more likely, etc.
Not to go too far off topic, but I bring it up as an example of how new native OS drivers could improve over what linux drivers are doing. Copying the linux drivers as is would lead to the same limitations.
It’s an ugly solution to a notorious problem. The best solution is obviously native drivers for everything, but it’s also untenable for a resource strapped alt-os project. so something’s got to give and this was seen as the best compromise. I agree though if this inadvertently becomes a long term fix, it’s not good for the future of microkernels. But again I cannot blame them, they’re just doing the best they can with what they’ve got.
Seems like reinventing the rump kernel.