Linked by snydeq on Wed 16th Dec 2009 20:13 UTC
OSNews, Generic OSes InfoWorld's Randall Kennedy takes an in-depth look at VMware Workstation 7, VirtualBox 3.1, and Parallels Desktop 4, three technologies at the heart of 'the biggest shake-up for desktop virtualization in years.' The shake-up, which sees Microsoft's once promising Virtual PC off in the Windows 7 XP Mode weeds, has put VirtualBox -- among the best free open source software available for Windows -- out front as a general-purpose VM, filling the void left by VMware's move to make Workstation more appealing to developers and admins. Meanwhile, Parallels finally offers a Desktop for Windows on par with its Mac product, as well as Workstation 4 Extreme, which delivers near native performance for graphics, disk, and network I/O.
Permalink for comment 400426
To read all comments associated with this story, please click here.
RE[6]: I've given up on Parallels
by gilboa on Sat 19th Dec 2009 11:11 UTC in reply to "RE[5]: I've given up on Parallels"
Member since:

I'm talking about loading an arbitrary, external binary driver, not a kernel module. There is a difference -- at least, there is a difference between a kernel module the way the Linux kernel does it, and a driver the way Windows does it. I'm talking about a way to not have to re-build all your third-party drivers every time you update the kernel, like I get to do now (which is in no way a hassle, and never fails or leaves my system in an unstable state! Really!).
Every time Red Hat pushes out a kernel update, I have to re-run the VirtualBox installer to re-build the kernel driver, and I get to un-install and re-install the nVidia driver. Because those drivers are actually kernel modules, that have to have bits of them built against the source-tree used to build the kernel that's meant to load them. Now, the kernel team could trivially provide a stable driver-loading interface, so that that didn't have to happen; they have quite deliberately elected not to do so.

As far as I remember, you can configure the kernel to ignore build versions (CONFIG_MODVERSIONS?). Most distribution (if not all), enable version to support in-order to -force- out-of-tree kernel modules to be recompiled against the latest kernel build - or at least against the latest kernel major build. (As far as I know, a driver that was build against RHEL 5.4 [164], can be used against all RHEL 5.4 series kernels [164.x]).
The reason for it has nothing to do with the kernel driver loading interface (?!?!?) and anything to do with the distribution's reluctance to be forced into keeping a stable API across major releases on one hand, and preventing comparability issues on the other - as even a minute change in one of the kernel's structures or API can crash your system (Hence, you are forced to rebuild your module against the latest kernel-headers).

- Gilboa

Reply Parent Score: 2