From: Matthew E. D. <matthew_e_dugan@GeorgiaSouthern.edu> - 2003-11-18 15:55:06
|
Good day, Today I start working on a Georgia Southern University (located in the South-East United States) research project covering User Mode Linux. The professor in charge wants to accomplish the following over the next few weeks: 1) Strip UML down to a compilable state containing only the virtual machine 2) Perform any clean ups and re-organizations 3) Take one of the removed pieces, verify its function 4) Perform any clean ups and re-organizations on the removed piece 5) Add the piece back into the build process 6) Repeat steps 3-5 until finished. He calls it a "verification process". At the end of which, he plans to publish a paper documenting what we do along with a detailed representation of the workings of the UML internals. I appreciate the opportunity to participate in this list server, and look forward to any recommendations any of you may have for this undertaking. Sincerely, Matthew Dugan md...@ge... |
From: Henrik N. <hn...@ma...> - 2003-11-18 17:32:08
|
On Tue, 18 Nov 2003, Matthew E. Dugan wrote: > 1) Strip UML down to a compilable state containing only the virtual machine UML does not have a virtual machine. It uses the HOST CPU directly for running both the UML kernel and applications ontop of the kernel. UML is an abstract hardware layer to the Linux kernel, allowing it to run as an ordinary Linux application with no dedicated hardware (real or emulated). This abstraction layer consists of several components * Various device drivers using host Linux system calls instead of hardware (serial devices, networking, console, etc). Many of these are optional and not required for operation. * Memory management using virtual memory rather than physical memory * Interception of system calls from applications running ontop of the UML kernel to have these calls executed by the UML kernel rather than the host kernel. Note: Between system calls and interrupts the application executes on the host CPU just like an application running outside the UML. * Interrupt "emulation" layer, allowing various events (filedescriptor ready for reading/writing etc) from the host kernel to be translated into a "interrupt" within the UML kernel to fit the device driver model of Linux. * Timer interrupts for context switching etc using the itimer function provided by the host kernel as interrupt source rather than a hardware timer. * Virtual filesystem driver providing transparent access to files on the host. (optional) * and many other components I have forgotten above... > 2) Perform any clean ups and re-organizations > 3) Take one of the removed pieces, verify its function > 4) Perform any clean ups and re-organizations on the removed piece > 5) Add the piece back into the build process > 6) Repeat steps 3-5 until finished. What I see most interesting with the UML hardware layer in the above is that it easily allows the above process to be applied to large parts of the Linux kernel in general a lot easier than if using real or even emulated hardware. Regards Henrik |