[ros-diffs] [tkreuzer] 34877: - add another missing export to ntoskrnl_amd64.def - fix LARGE_INTEGER to pointer cast - add more drivers to build
tkreuzer at svn.reactos.org
tkreuzer at svn.reactos.org
Mon Jul 28 02:47:29 CEST 2008
- Previous message: [ros-diffs] [ros-arm-bringup] 34876: Looks like this address space nonsense made even less sense than originally understood. The kernel address space was something created very early-on, and associated with a global variable that actually contained the address space itself (so it wasn't part of any process). Its locks however, were associated to the "current process", which, when this function is called, is the idle process (which later is cloned into the initial system process). Shortly thereafter, the address space of the "current process" (still, at this point, the idle process) was initialized with the function reserved for real processes (MmInitializeProcessAddressSpace), which among other things, performed a couple of user-mode mappings (which are irrelevant and should not be part of the system process address space). This created a weird schism: the kernel address space was actually a global variable associated with no process at all, while the kernel process had its own address space as well (which was not the kernel address space). It's a miracle this didn't screw anything up especially since whether or not the address space has an owner determined the lowest address (which means that if the kernel process allocated a memory with its *own* address space, the code would think it was a user-mode process). This patch gets rid of the kernel address space as a static structure, and instead makes it a pointer into the idle/system process' address space. It also gets rid of MmInitializeKernelAddresSpace and instead makes use of the existing MmInitializeHandBuiltProcess, cleaning up the user-mode allocations previously made. Even though all address spaces now have an owner and are part of a process, MmGetAddressSpaceOwner will still return NULL for now, to remain backwards compatible with legacy code.
- Next message: [ros-diffs] [ros-arm-bringup] 34878: There is no point in saving the address of the address space lock in the address space structure anymore, since this lock is always the address creation lock of the owner process, and there's always an owner process now.
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
Author: tkreuzer
Date: Sun Jul 27 19:47:28 2008
New Revision: 34877
URL: http://svn.reactos.org/svn/reactos?rev=34877&view=rev
Log:
- add another missing export to ntoskrnl_amd64.def
- fix LARGE_INTEGER to pointer cast
- add more drivers to build
Modified:
branches/ros-amd64-bringup/reactos/ReactOS-amd64.rbuild
branches/ros-amd64-bringup/reactos/drivers/storage/floppy/floppy.c
branches/ros-amd64-bringup/reactos/ntoskrnl/ntoskrnl_amd64.def
Modified: branches/ros-amd64-bringup/reactos/ReactOS-amd64.rbuild
URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/ReactOS-amd64.rbuild?rev=34877&r1=34876&r2=34877&view=diff
==============================================================================
--- branches/ros-amd64-bringup/reactos/ReactOS-amd64.rbuild [iso-8859-1] (original)
+++ branches/ros-amd64-bringup/reactos/ReactOS-amd64.rbuild [iso-8859-1] Sun Jul 27 19:47:28 2008
@@ -93,14 +93,12 @@
<directory name="drivers">
<directory name="base">
- <directory name="bootvid">
- <xi:include href="drivers/base/bootvid/bootvid.rbuild" />
- </directory>
- <directory name="kdcom">
- <xi:include href="drivers/base/kdcom/kdcom.rbuild" />
- </directory>
+ <xi:include href="drivers/base/directory.rbuild" />
</directory>
<directory name="filesystems">
+ <directory name="cdfs">
+ <xi:include href="drivers/filesystems/cdfs/cdfs.rbuild" />
+ </directory>
<directory name="fastfat">
<xi:include href="drivers/filesystems/fastfat/vfatfs.rbuild" />
</directory>
@@ -116,11 +114,23 @@
<xi:include href="drivers/network/tcpip/tcpip.rbuild" />
</directory>
</directory>
+ <directory name="setup">
+ <xi:include href="drivers/setup/directory.rbuild" />
+ </directory>
<directory name="storage">
<directory name="class">
+ <directory name="cdrom">
+ <xi:include href="drivers/storage/class/cdrom/cdrom.rbuild" />
+ </directory>
<directory name="class2">
<xi:include href="drivers/storage/class/class2/class2.rbuild" />
</directory>
+ <directory name="disk">
+ <xi:include href="drivers/storage/class/disk/disk.rbuild" />
+ </directory>
+ </directory>
+ <directory name="floppy">
+ <xi:include href="drivers/storage/floppy/floppy.rbuild" />
</directory>
<directory name="ide">
<directory name="atapi">
Modified: branches/ros-amd64-bringup/reactos/drivers/storage/floppy/floppy.c
URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/drivers/storage/floppy/floppy.c?rev=34877&r1=34876&r2=34877&view=diff
==============================================================================
--- branches/ros-amd64-bringup/reactos/drivers/storage/floppy/floppy.c [iso-8859-1] (original)
+++ branches/ros-amd64-bringup/reactos/drivers/storage/floppy/floppy.c [iso-8859-1] Sun Jul 27 19:47:28 2008
@@ -520,7 +520,7 @@
if(AddressSpace == 0)
gControllerInfo[gNumberOfControllers].BaseAddress = MmMapIoSpace(TranslatedAddress, FDC_PORT_BYTES, MmNonCached);
else
- gControllerInfo[gNumberOfControllers].BaseAddress = (PUCHAR)TranslatedAddress.u.LowPart;
+ gControllerInfo[gNumberOfControllers].BaseAddress = (PUCHAR)(ULONG_PTR)TranslatedAddress.QuadPart;
}
else if(PartialDescriptor->Type == CmResourceTypeDma)
Modified: branches/ros-amd64-bringup/reactos/ntoskrnl/ntoskrnl_amd64.def
URL: http://svn.reactos.org/svn/reactos/branches/ros-amd64-bringup/reactos/ntoskrnl/ntoskrnl_amd64.def?rev=34877&r1=34876&r2=34877&view=diff
==============================================================================
--- branches/ros-amd64-bringup/reactos/ntoskrnl/ntoskrnl_amd64.def [iso-8859-1] (original)
+++ branches/ros-amd64-bringup/reactos/ntoskrnl/ntoskrnl_amd64.def [iso-8859-1] Sun Jul 27 19:47:28 2008
@@ -14,6 +14,7 @@
KeGetCurrentProcessorNumber
RtlConvertUlongToLargeInteger
RtlExtendedIntegerMultiply
+KeQueryTickCount
;
; original:
CcCanIWrite
- Previous message: [ros-diffs] [ros-arm-bringup] 34876: Looks like this address space nonsense made even less sense than originally understood. The kernel address space was something created very early-on, and associated with a global variable that actually contained the address space itself (so it wasn't part of any process). Its locks however, were associated to the "current process", which, when this function is called, is the idle process (which later is cloned into the initial system process). Shortly thereafter, the address space of the "current process" (still, at this point, the idle process) was initialized with the function reserved for real processes (MmInitializeProcessAddressSpace), which among other things, performed a couple of user-mode mappings (which are irrelevant and should not be part of the system process address space). This created a weird schism: the kernel address space was actually a global variable associated with no process at all, while the kernel process had its own address space as well (which was not the kernel address space). It's a miracle this didn't screw anything up especially since whether or not the address space has an owner determined the lowest address (which means that if the kernel process allocated a memory with its *own* address space, the code would think it was a user-mode process). This patch gets rid of the kernel address space as a static structure, and instead makes it a pointer into the idle/system process' address space. It also gets rid of MmInitializeKernelAddresSpace and instead makes use of the existing MmInitializeHandBuiltProcess, cleaning up the user-mode allocations previously made. Even though all address spaces now have an owner and are part of a process, MmGetAddressSpaceOwner will still return NULL for now, to remain backwards compatible with legacy code.
- Next message: [ros-diffs] [ros-arm-bringup] 34878: There is no point in saving the address of the address space lock in the address space structure anymore, since this lock is always the address creation lock of the owner process, and there's always an owner process now.
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Ros-diffs
mailing list