4 ms·

Someone has to write the drivers for the hypervisor. A hypervisor is nothing but a minimal OS that provides a different set of resource management guarantees. Y

by nly 13y ago

Someone has to write the drivers for the hypervisor. A hypervisor is nothing but a minimal OS that provides a different set of resource management guarantees. You can't make many of those guarantees without access to the hardware.

derefr 13y ago
Yes, agreed fully. The point of the distinction, here, is not that everyone can avoid writing drivers--somebody, somewhere has got to write them into something. The hypervisor is in fact an Operating System in every sense of the term (and I assumed people already knew this and would take it for granted--Xen is an OS; Linux doing KVM or LXC is (obviously) an OS; and so forth.) But the point, here, is that the type of "OS" people talk about when they say they're "designing an OS"; and the "OS" Microsoft, or Apple, or Google, or Canonical are selling you; has everything to do with how processes are managed, memory is allocated, IPC is done, etc.; and nothing to do with drivers. OS devs don't want to think about drivers; they just want them there. Driver support is, in other words, a commodity. And what do we (hopefully) do with commodities, in the software world? Why, we break them out into (usually BSD/zlib-licensed) libraries, with a consortium of companies co-developing it for everyone's benefit! See, for example, Webkit. Here's another way to approach the idea. Imagine if (for example) every OS was actually based on Linux; if Linux was a kernel "kit" that provided all the drivers, but then left a big pluggable hole where Microsoft and Apple and everyone else had inserted their own implementation of the stuff that matters to people in an OS. That'd be neat, wouldn't it? Everyone would be using the same drivers; any update to the driver exokernel would help out everyone equally; all the proprietary hardware manufacturers would be forced to contribute to it because of its monopsony status. It'd have quite a few advantages[1], most importantly that as long as [major OS] supported your device, all the little niche/hobbyist OSes would get support too, for free. Just like, today, if Chrome supports some weird new CSS trick, then you can expect it'll also work in Safari, on iOS, in node-webkit, and on random Android browsers (even most of the crap proprietary ones.) Suddenly, writing your own OS isn't such a daunting task. The reason this hasn't happened, obviously, is that "Linux" isn't just drivers; it's all the other stuff that makes Linux Linux, instead of Windows or OSX. So you can't build on top of Linux without accepting the Linux memory-manager, and the Linux process model, and the Linux scheduler, and the Linux VFS, ad nauseam. The reason that this hasn't happened, in other words, is that we aren't making this distinction. --- [1] It'd also have the obvious disadvantage of giving malware authors only one system to target all their exploits toward--but that also means that all the security researchers would be working together to harden the exokernel, out in the open, with no possibility of "responsible disclosure." And obviously, groups like OpenBSD would be still going their own way with their own exokernel, just like they always have. One of the main advantages of using the hypercalls as the point-of-contact is that it standardizes and contractualizes the interface between the driver-exokernel and the userland-managing-kernel. If we pick a standard set of hypercalls--a modern version of a BIOS API--then you can swap out the Linux driver-exokernel for OpenBSD's version, or any other version, and it'd interoperate with whatever userland-managing-kernel(s) you wanted to use.
- nly 13y ago
  I agree with your sentiment but when someone comes along with the smart idea of running a knife between the business end of the OS and the driver stack we end up with abominations like UEFI that just push the OS's duties in to the firmware. The API of a driver is just as important as the bits they twiddle because it insidiously chains you to a particular abstraction model, i.e. a specific state machine you're building on top of hardware state. This is why Linux doesn't maintain a stable driver API. If you enforce driver API stability then you're boned down the line when it comes to moving from, say, a synchronous model to an asynchronous one.

by nly 13y ago

derefr 13y ago

Yes, agreed fully. The point of the distinction, here, is not that everyone can avoid writing drivers--somebody, somewhere has got to write them into something. The hypervisor is in fact an Operating System in every sense of the term (and I assumed people already knew this and would take it for granted--Xen is an OS; Linux doing KVM or LXC is (obviously) an OS; and so forth.) But the point, here, is that the type of "OS" people talk about when they say they're "designing an OS"; and the "OS" Microsoft, or Apple, or Google, or Canonical are selling you; has everything to do with how processes are managed, memory is allocated, IPC is done, etc.; and nothing to do with drivers. OS devs don't want to think about drivers; they just want them there. Driver support is, in other words, a commodity. And what do we (hopefully) do with commodities, in the software world? Why, we break them out into (usually BSD/zlib-licensed) libraries, with a consortium of companies co-developing it for everyone's benefit! See, for example, Webkit. Here's another way to approach the idea. Imagine if (for example) every OS was actually based on Linux; if Linux was a kernel "kit" that provided all the drivers, but then left a big pluggable hole where Microsoft and Apple and everyone else had inserted their own implementation of the stuff that matters to people in an OS. That'd be neat, wouldn't it? Everyone would be using the same drivers; any update to the driver exokernel would help out everyone equally; all the proprietary hardware manufacturers would be forced to contribute to it because of its monopsony status. It'd have quite a few advantages[1], most importantly that as long as [major OS] supported your device, all the little niche/hobbyist OSes would get support too, for free. Just like, today, if Chrome supports some weird new CSS trick, then you can expect it'll also work in Safari, on iOS, in node-webkit, and on random Android browsers (even most of the crap proprietary ones.) Suddenly, writing your own OS isn't such a daunting task. The reason this hasn't happened, obviously, is that "Linux" isn't just drivers; it's all the other stuff that makes Linux Linux, instead of Windows or OSX. So you can't build on top of Linux without accepting the Linux memory-manager, and the Linux process model, and the Linux scheduler, and the Linux VFS, ad nauseam. The reason that this hasn't happened, in other words, is that we aren't making this distinction. --- [1] It'd also have the obvious disadvantage of giving malware authors only one system to target all their exploits toward--but that also means that all the security researchers would be working together to harden the exokernel, out in the open, with no possibility of "responsible disclosure." And obviously, groups like OpenBSD would be still going their own way with their own exokernel, just like they always have. One of the main advantages of using the hypercalls as the point-of-contact is that it standardizes and contractualizes the interface between the driver-exokernel and the userland-managing-kernel. If we pick a standard set of hypercalls--a modern version of a BIOS API--then you can swap out the Linux driver-exokernel for OpenBSD's version, or any other version, and it'd interoperate with whatever userland-managing-kernel(s) you wanted to use.

nly 13y ago
I agree with your sentiment but when someone comes along with the smart idea of running a knife between the business end of the OS and the driver stack we end up with abominations like UEFI that just push the OS's duties in to the firmware. The API of a driver is just as important as the bits they twiddle because it insidiously chains you to a particular abstraction model, i.e. a specific state machine you're building on top of hardware state. This is why Linux doesn't maintain a stable driver API. If you enforce driver API stability then you're boned down the line when it comes to moving from, say, a synchronous model to an asynchronous one.