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.
Thread beginning with comment 400204
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: I've given up on Parallels
by gilboa on Fri 18th Dec 2009 00:51 UTC in reply to "RE[3]: I've given up on Parallels"
gilboa
Member since:
2005-07-06

I believe that reasons that the Linux kernel has no driver-loading API are entirely political.


Uggggh?!?!?? *

- Gilboa
* 1. You can load and unload modules from kernel mode code (ugly but working).
2. You can load and unload modules from user mode code. (Exec never killed anyone).
3. Or were you talking about GPL-only __symbol_get?

Edited 2009-12-18 00:53 UTC

Reply Parent Score: 2

boldingd Member since:
2009-02-19

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.

Reply Parent Score: 3

gilboa Member since:
2005-07-06

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