KVM and beyond: bare metal apps and microapp multi-threading
Linux KVM (Kernel-based Virtual-Machine) allows Linux to be a hypervisor (or a "super" supervisor or meta-operating system) and control other OS (including multiple copies of Linux).
What KVM (or any hypervisor, like Xen or rHype) allows is for non-OS to run in a partition (the isolated environment). That is, individual applications can be written to run on "bare-metal" or OS-less environment. Or anything in between. The question is how much does the partition handle on its own without a real OS. Either you convert existing libraries to work in bare-metal mode or you make API calls outside of the partition (either through hypervisor calls or IO read/write or virtualized-HW interrupts which are trapped by the hypervisor and passed to another OS-partition or handled directly by the hypervisor (like in the case of KVM)).
This is somewhat like a microkernel, where a small kernel distributes real work outside in the user mode rather than trying to do everything in the supervisor mode. Taking this concept further, a microapp maybe the best way to take advantage of multi-core or multi-threaded system. Be it a game or simulator, it is hard for an application to take advantage of a multi-core system, since an app is usually broken down in terms of large chunks of functionality. As a programmer, it's natural for me to think in one long sequential functionality rather than minimal, small functions stitched together by a microapp "kernel." Yet, until microapps become common, I think it will be very hard to take advantage of multiple cores efficiently. The problem with microapps is with design, debug and maintenance. Debug is challenging enough on a multi-core system, and microapps would only exasperate the complexity. That is, it's easy enough to debug individual microapp but once multiple microapps are running and interacting then the fun begins! I believe that the only way to manage this complexity to have equality complex simulator/debugger.
What those complexities might be will be explored in the future....
Copyright 2007, DannyHSDad, All Rights Reserved.
What KVM (or any hypervisor, like Xen or rHype) allows is for non-OS to run in a partition (the isolated environment). That is, individual applications can be written to run on "bare-metal" or OS-less environment. Or anything in between. The question is how much does the partition handle on its own without a real OS. Either you convert existing libraries to work in bare-metal mode or you make API calls outside of the partition (either through hypervisor calls or IO read/write or virtualized-HW interrupts which are trapped by the hypervisor and passed to another OS-partition or handled directly by the hypervisor (like in the case of KVM)).
This is somewhat like a microkernel, where a small kernel distributes real work outside in the user mode rather than trying to do everything in the supervisor mode. Taking this concept further, a microapp maybe the best way to take advantage of multi-core or multi-threaded system. Be it a game or simulator, it is hard for an application to take advantage of a multi-core system, since an app is usually broken down in terms of large chunks of functionality. As a programmer, it's natural for me to think in one long sequential functionality rather than minimal, small functions stitched together by a microapp "kernel." Yet, until microapps become common, I think it will be very hard to take advantage of multiple cores efficiently. The problem with microapps is with design, debug and maintenance. Debug is challenging enough on a multi-core system, and microapps would only exasperate the complexity. That is, it's easy enough to debug individual microapp but once multiple microapps are running and interacting then the fun begins! I believe that the only way to manage this complexity to have equality complex simulator/debugger.
What those complexities might be will be explored in the future....
Copyright 2007, DannyHSDad, All Rights Reserved.
Labels: virtualization
posted by DannyHSDad at
4:20 AM
