xxxxx@hotmail.com wrote:
thank you for the response and for the correction on the fact that article speaks of 32 bit systems. OK then just for the sake of the argument and in keeping with 64 bit systems where the virtual space is much larger. Would there be a kernel component that resides in the virtual 8-terabyte address space that an application on a 64 bit resides ? My question as above if there is such a kernel component within this virtual address space does it play any role in communicating IO data such as TCP to the user application residing within the same virtual address space ? Such as the mapping you talked about above ? if no then what is the purpose of the kernel component which resides in the same virtual address space as the application ?
I don’t think your mental model of the system is quite correct yet.
Let’s say we freeze the whole system at a given point in time. In the
lower parts of the virtual address space, we have the currently running
application, its DLLs, and the user-mode operating system DLLS like
gdi32.dll and user32.dll. In the upper parts of the virtual address
space, we have the operating system kernel, add-in kernel modules,
kernel drivers, page tables, and so on. EVERYTHING you need to run the
entire computer is in that address space. Let’s say the application
calls “recv” on a socket. The CPU starts executing in the user-mode
Windows sockets DLL, ws2_32.dll. That function will eventually call
ReadFile, in the user-mode DLL kernel32.dll.
ReadFile then makes a syscall which shifts the CPU into kernel mode, and
ends up calling into ZwReadFile in ntoskrnl.exe. Now, that’s just a
regular DLL, except that it lives in the kernel part of the process
space. It eventually will create an I/O request and call IoCallDriver,
which eventually calls into the network driver stack. The network
drivers all live in that kernel part of the address space, so these are
just function calls that happen to be done while the CPU is in ring 0
(kernel mode). While that’s going on, the rest of the address space
(including the user-mode portion) is all still there. These kernel
drivers can copy to user-mode addresses just by writing to a local pointer.
Eventually, the I/O request is completed, the functions return, we mode
the CPU back to ring 3 (user mode), and the application continues on.
When the system wants to start running a different application, it just
switches the page tables for the lower half of the virtual space. The
upper half (with the kernel) remains the same, always available.
So, it’s not like the operating system lives in some separate space.
The operating system is in memory at all times.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.