Comment Re:Thanks, but no thanks. (Score 2) 159
Your assessment of our patches is not really on target. I am not sure what you are talking about wben you refer to a separate "VM/schduler/etc". One problem is that the abbreviation VM can mean either Virtual Machine or Virtual Memory (subsystem). It is not really clear which are you are talking about. We do create a virtual machine environment but try to make maximal use of of the x86 chip (i.e. we try to avoid as much emulation as we can).
We move the Linux GDT because Linux doesn't really care where it's GDT goes, but WINDOWs does! We need more extensive LDT support than provided. We also want switch-in and switch-out hooks so that we can save and restore processor state that LINUX does not save and restore for us.
We also have a "return to user mode" hook so that we can deliver virtual interrupts (the virtual machine equivalent of a signal) whenever a return to user mode occurs. In addition, we have a task exit hook which allows us to clean up whenever the virtual machine process exits.
We have some Virtual Memory hooks because Windows thinks it is managing memory. We provide virtual-virtual memory and to do this with good performance, we need a better interface than "mmap" alone can provide.
We could "steal" and lock a large chunk of memory for Window's exclusive use, but we would rather play in the memory pool with everyone else. I.e. if windows is idle and not using memory, then it should be able to be paged out and used by other processes.
There are, perhaps, ways that we could better take advantage of what Linux has to offer, but our product also runs on SCO OpenServer 5 and SCO UnixWare. We wanted to get something that is implemented in a pretty consistent way on all the operating systems. In addition, up until the merger of TreLOS and NeTraverse, we have been pretty short staffed and been trying to get the biggest bang out of our development time. So to some degree the implementation of the interface into Linux was the one we could do the fastest and still maintain excellent performance.
Also, just to clear up a few other misunderstandings: We do NOT let windows run in ring 0! We also DO use loadable modules. However our modules require the hooks that we have placed in the kernel.
We move the Linux GDT because Linux doesn't really care where it's GDT goes, but WINDOWs does! We need more extensive LDT support than provided. We also want switch-in and switch-out hooks so that we can save and restore processor state that LINUX does not save and restore for us.
We also have a "return to user mode" hook so that we can deliver virtual interrupts (the virtual machine equivalent of a signal) whenever a return to user mode occurs. In addition, we have a task exit hook which allows us to clean up whenever the virtual machine process exits.
We have some Virtual Memory hooks because Windows thinks it is managing memory. We provide virtual-virtual memory and to do this with good performance, we need a better interface than "mmap" alone can provide.
We could "steal" and lock a large chunk of memory for Window's exclusive use, but we would rather play in the memory pool with everyone else. I.e. if windows is idle and not using memory, then it should be able to be paged out and used by other processes.
There are, perhaps, ways that we could better take advantage of what Linux has to offer, but our product also runs on SCO OpenServer 5 and SCO UnixWare. We wanted to get something that is implemented in a pretty consistent way on all the operating systems. In addition, up until the merger of TreLOS and NeTraverse, we have been pretty short staffed and been trying to get the biggest bang out of our development time. So to some degree the implementation of the interface into Linux was the one we could do the fastest and still maintain excellent performance.
Also, just to clear up a few other misunderstandings: We do NOT let windows run in ring 0! We also DO use loadable modules. However our modules require the hooks that we have placed in the kernel.
