Linked by Thom Holwerda on Thu 28th May 2009 12:08 UTC, submitted by lemur2
Linux There are several ways to run Windows programs on Linux (virtualisation, WINE) and vice versa really isn't a problem either with Cygwin, or better yet, native ports thanks to the Windows variants of Gtk+ and Qt. Still, what if Windows support was built straight into the Linux kernel? Is something like that even possible? Sure it is, and the Chinese figured it'd be an interesting challenge, and called it the Linux Unified Kernel.
Thread beginning with comment 365780
To read all comments associated with this story, please click here.
System calls clarification
by elahav on Thu 28th May 2009 13:54 UTC
elahav
Member since:
2009-05-28

Using software interrupts for system calls is the old and slow way of crossing the user/kernel boundary. Modern Linux kernels on the x86 use the sysenter instruction (if available on the hardware) and I imagine that Windows does the same thing. Resorting to software interrupts is going to have an adverse effect on performance, especially for system-call heavy workloads.

On a different subject, I can understand the appeal of this project from a research point of view, but fail to see any real advantage coming out of it. There are proper (TM) ways for running Windows applications on Linux and vice versa (i.e., compatibility layers such as WINE) and for running multiple OS kernels (virtualisation).

RE: System calls clarification
by Dasher42 on Thu 28th May 2009 18:17 in reply to "System calls clarification"
Dasher42 Member since:
2007-04-05

This is a kernel module which does the process and thread management as opposed to a userspace wineserver. Most of the rest of WINE is used straightaway and without the resource bloat you'd see elsewhere. I actually think this is pretty darn handy, though I'll want to see this stuff secured.

Reply Parent Bookmark Score: 1

elahav Member since:
2009-05-28

This is a kernel module which does the process and thread management as opposed to a userspace wineserver.


So what? I see no advantage in that. Performance-wise, the only reason to implement something as a kernel module is to reduce the number of user/kernel mode switches and data copies, which I don't think that you achieve in this case. Other than that, the kernel has no magic power - only the nightmare of having more code executing at ring 0.

As far as I can tell, performance has never been a shortcoming of WINE. The only problem was (and, to a large extent, is) lack of completeness in the implementation.

Reply Parent Bookmark Score: 3