Quoting "Miller, Marc" <[EMAIL PROTECTED]>:
I recently came across an article claiming that virtualization "liberates"
the OS from the hardware, basically implying that the hypervisor can now
contain all of the drivers and that the OS just needs to have a standard
abstraction layer for accessing the true driver involved.
Funny, I thought the OS's job was to manage the hardware so that the
applications wouldn't have to. It's almost like outsourcing: in DOS,
applications had to know what graphics card, printer, mouse, etc. you were
using. Linux and Windows standardized this by making device management part
of its job. (and yes, UNIX already did this) now hardware management is
going down another level of the stack.
Of course, this shift in thinking hits at about the same time that drivers
have become a hot topic for Linux. Hardware vendors don't want to have to
provide support to OEMs for several versions of the driver (Red Hat, SUSE,
Ubuntu, etc.), some hardware vendors are reluctant to reveal their code (for
a range of reasons), and Linux kernel developers are reluctant to
standardize the API.
If driver management becomes the role of the hypervisor or even of the
firmware and there is no "host" operating system to speak of, will Linux
drivers still matter?
Marc J. Miller
Open Source Relations Manager, AMD Developer Outreach team
Board Member, Linux Foundation
Linux Foundation Desktop/Client Linux Technical Co-Chairman
W: +1 (800) 538-8450 x43325
M: +1 (408) 425-4017
I think the reality is that it just moves the problem to another layer, it
doesn't "solve" the problem. If you look at hardware vendors (like us, for
instance, just to pick someone at random ;-), when we deliver new platforms,
they occasionally support some latest and greatest feature set or performance,
which requires a new driver. How do we deploy that hardware? Well,
we'll need
a hypervisor in that world to enable that hardware. And, some of those new
hardware elements occasionally need knowledge of the operating system, so
sometimes a virtual network driver may need a new feature added to talk to the
new feature of the hardware that is now supported by the new virtualization
layer. So, you have three layers in some case that need to be coordinated to
enable the latest and greatest hardware components.
However, virtualization will hide a lot of details for "similar" hardware from
the virtualized OS instances. But, that virtual environment may not be able
to always run on the latest hardware because the hypervisor does not have
appropriate driver support.
In short, pushing the problem down to the hypervisor will help in some cases,
but will probably make things harder in a few other cases. Instead of pushing
drivers to mainline Linux and the distros, we'll all have to push them to the
latest hypervisor (Xen, Linux/KVM, VMware ESX, etc.) before the software stack
can take advantage of the latest hardware.
Not a panacea.
gerrit
_______________________________________________
Desktop_architects mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/desktop_architects
