2007-12-15 16:18:49 +00:00
|
|
|
/*
|
|
|
|
* PROJECT: ReactOS Kernel
|
|
|
|
* LICENSE: GPL - See COPYING in the top level directory
|
|
|
|
* FILE: ntoskrnl/fstub/halstub.c
|
|
|
|
* PURPOSE: I/O Stub HAL Routines
|
|
|
|
* PROGRAMMERS: Alex Ionescu (alex.ionescu@reactos.org)
|
[NTOSKRNL]
Revert r51017 that was reverting r51016.
In fact, it seems that cmlib assert error, whatever that eats randomly doesn't come from software issue inside ReactOS, but from a build issue.
Indeed, as you may see in the different tests I performed it shows that the same build produces the same failure, again and again. But, new build shows that there is no assert anylonger with that commit.
Don't ask me why or how it happens, I just don't get it.
But most of the time, it works, no one knows why ("as usual" (tm)). But it's cool.
Someone from BE team and/or buildslaves managers should take a serious look at this issue.
Just in case: if that commit re-hits cmlib assert, don't blame it immediatly, just commit something else, and see whether trunk is still broken.
But, as you can see in testman, we have now test results for r51016 ;-)
svn path=/trunk/; revision=51025
2011-03-12 12:56:36 +00:00
|
|
|
Pierre Schweitzer (pierre.schweitzer@reactos.org)
|
2007-12-15 16:18:49 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
/* INCLUDES ******************************************************************/
|
|
|
|
|
|
|
|
#include <ntoskrnl.h>
|
|
|
|
#define NDEBUG
|
2008-08-30 16:31:06 +00:00
|
|
|
#include <debug.h>
|
2007-12-15 16:18:49 +00:00
|
|
|
|
|
|
|
/* GLOBALS *******************************************************************/
|
|
|
|
|
|
|
|
HAL_DISPATCH HalDispatchTable =
|
|
|
|
{
|
|
|
|
HAL_DISPATCH_VERSION,
|
[NTOSKRNL]
Revert r51017 that was reverting r51016.
In fact, it seems that cmlib assert error, whatever that eats randomly doesn't come from software issue inside ReactOS, but from a build issue.
Indeed, as you may see in the different tests I performed it shows that the same build produces the same failure, again and again. But, new build shows that there is no assert anylonger with that commit.
Don't ask me why or how it happens, I just don't get it.
But most of the time, it works, no one knows why ("as usual" (tm)). But it's cool.
Someone from BE team and/or buildslaves managers should take a serious look at this issue.
Just in case: if that commit re-hits cmlib assert, don't blame it immediatly, just commit something else, and see whether trunk is still broken.
But, as you can see in testman, we have now test results for r51016 ;-)
svn path=/trunk/; revision=51025
2011-03-12 12:56:36 +00:00
|
|
|
xHalQuerySystemInformation,
|
|
|
|
xHalSetSystemInformation,
|
|
|
|
xHalQueryBusSlots,
|
2007-12-15 16:18:49 +00:00
|
|
|
0,
|
|
|
|
xHalExamineMBR,
|
|
|
|
xHalIoAssignDriveLetters,
|
|
|
|
xHalIoReadPartitionTable,
|
|
|
|
xHalIoSetPartitionInformation,
|
|
|
|
xHalIoWritePartitionTable,
|
[NTOSKRNL]
Revert r51017 that was reverting r51016.
In fact, it seems that cmlib assert error, whatever that eats randomly doesn't come from software issue inside ReactOS, but from a build issue.
Indeed, as you may see in the different tests I performed it shows that the same build produces the same failure, again and again. But, new build shows that there is no assert anylonger with that commit.
Don't ask me why or how it happens, I just don't get it.
But most of the time, it works, no one knows why ("as usual" (tm)). But it's cool.
Someone from BE team and/or buildslaves managers should take a serious look at this issue.
Just in case: if that commit re-hits cmlib assert, don't blame it immediatly, just commit something else, and see whether trunk is still broken.
But, as you can see in testman, we have now test results for r51016 ;-)
svn path=/trunk/; revision=51025
2011-03-12 12:56:36 +00:00
|
|
|
xHalHandlerForBus,
|
|
|
|
xHalReferenceHandler,
|
|
|
|
xHalReferenceHandler,
|
|
|
|
xHalInitPnpDriver,
|
|
|
|
xHalInitPowerManagement,
|
2007-12-15 16:18:49 +00:00
|
|
|
(pHalGetDmaAdapter) NULL,
|
2011-03-10 21:02:21 +00:00
|
|
|
xHalGetInterruptTranslator,
|
[NTOSKRNL]
Revert r51017 that was reverting r51016.
In fact, it seems that cmlib assert error, whatever that eats randomly doesn't come from software issue inside ReactOS, but from a build issue.
Indeed, as you may see in the different tests I performed it shows that the same build produces the same failure, again and again. But, new build shows that there is no assert anylonger with that commit.
Don't ask me why or how it happens, I just don't get it.
But most of the time, it works, no one knows why ("as usual" (tm)). But it's cool.
Someone from BE team and/or buildslaves managers should take a serious look at this issue.
Just in case: if that commit re-hits cmlib assert, don't blame it immediatly, just commit something else, and see whether trunk is still broken.
But, as you can see in testman, we have now test results for r51016 ;-)
svn path=/trunk/; revision=51025
2011-03-12 12:56:36 +00:00
|
|
|
xHalStartMirroring,
|
|
|
|
xHalEndMirroring,
|
|
|
|
xHalMirrorPhysicalMemory,
|
2010-03-08 20:37:24 +00:00
|
|
|
xHalEndOfBoot,
|
[NTOSKRNL]
Revert r51017 that was reverting r51016.
In fact, it seems that cmlib assert error, whatever that eats randomly doesn't come from software issue inside ReactOS, but from a build issue.
Indeed, as you may see in the different tests I performed it shows that the same build produces the same failure, again and again. But, new build shows that there is no assert anylonger with that commit.
Don't ask me why or how it happens, I just don't get it.
But most of the time, it works, no one knows why ("as usual" (tm)). But it's cool.
Someone from BE team and/or buildslaves managers should take a serious look at this issue.
Just in case: if that commit re-hits cmlib assert, don't blame it immediatly, just commit something else, and see whether trunk is still broken.
But, as you can see in testman, we have now test results for r51016 ;-)
svn path=/trunk/; revision=51025
2011-03-12 12:56:36 +00:00
|
|
|
xHalMirrorPhysicalMemory
|
2007-12-15 16:18:49 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
HAL_PRIVATE_DISPATCH HalPrivateDispatchTable =
|
|
|
|
{
|
|
|
|
HAL_PRIVATE_DISPATCH_VERSION,
|
[NTOSKRNL]
Revert r51017 that was reverting r51016.
In fact, it seems that cmlib assert error, whatever that eats randomly doesn't come from software issue inside ReactOS, but from a build issue.
Indeed, as you may see in the different tests I performed it shows that the same build produces the same failure, again and again. But, new build shows that there is no assert anylonger with that commit.
Don't ask me why or how it happens, I just don't get it.
But most of the time, it works, no one knows why ("as usual" (tm)). But it's cool.
Someone from BE team and/or buildslaves managers should take a serious look at this issue.
Just in case: if that commit re-hits cmlib assert, don't blame it immediatly, just commit something else, and see whether trunk is still broken.
But, as you can see in testman, we have now test results for r51016 ;-)
svn path=/trunk/; revision=51025
2011-03-12 12:56:36 +00:00
|
|
|
xHalHandlerForBus,
|
|
|
|
(pHalHandlerForConfigSpace)xHalHandlerForBus,
|
|
|
|
xHalLocateHiberRanges,
|
|
|
|
xHalRegisterBusHandler,
|
2010-03-08 20:37:24 +00:00
|
|
|
xHalSetWakeEnable,
|
[NTOSKRNL]
Revert r51017 that was reverting r51016.
In fact, it seems that cmlib assert error, whatever that eats randomly doesn't come from software issue inside ReactOS, but from a build issue.
Indeed, as you may see in the different tests I performed it shows that the same build produces the same failure, again and again. But, new build shows that there is no assert anylonger with that commit.
Don't ask me why or how it happens, I just don't get it.
But most of the time, it works, no one knows why ("as usual" (tm)). But it's cool.
Someone from BE team and/or buildslaves managers should take a serious look at this issue.
Just in case: if that commit re-hits cmlib assert, don't blame it immediatly, just commit something else, and see whether trunk is still broken.
But, as you can see in testman, we have now test results for r51016 ;-)
svn path=/trunk/; revision=51025
2011-03-12 12:56:36 +00:00
|
|
|
xHalSetWakeAlarm,
|
|
|
|
xHalTranslateBusAddress,
|
|
|
|
(pHalAssignSlotResources)xHalTranslateBusAddress,
|
- Stub out DbgKdWriteVirtualMemoryApi, DbgKdReadPhysicalMemoryApi, DbgKdWritePhysicalMemoryApi, DbgKdWriteBreakPointExApi, DbgKdRestoreBreakPointExApi, DbgKdSearchMemoryApi and DbgKdFillMemoryApi cases more properly.
- Fail on physical memory write like we do for read too.
- Don't handle OldVlm1/2 as they appear to be deprecated and unhandled in Windows.
- Implement HalHaltSystem to halt execution in a portable way. Default to xHalHaltSystem, a simple infinite loop, if we get called before HAL has initialized. Use this in KiBugCheckDebugBreak and the system shutdown handler instead of x86/AMD64/ARM intrinsics.
- Don't try to halt the CPU if KeBugCheck has been called 3 times or more -- if this happens, something has gone very wrong, and we shouldn't try to do anything special. Just loop infinitely.
- Fix KiBugCheckDebugBreak -- it shouldn't halt execution when called for the first chance as bugcheck callbacks have not been invoked at this point (nor has the BSOD been displayed). Use SEH to protect against a crash instead of checking KdDebuggerNotPresent as the debugger, if it is present, *could* disconnect while the trap is being handled. Also, don't halt execution if the debugger handled the breakpoint, just break again.
- Don't call MmMapIoSpace from HalpReboot! The reboot might take place at elevated IRQL (as high as HIGH_LEVEL if called from KeBugCheck), and thus can't use any Mm support routines. Use a PTE from the reserved HAL region and map it ourselves instead as done in the BIOS call code.
- Acquire the display ownership in HalReturnToFirmware in case the caller hasn't done so (as done in the KD reboot routine, for example).
- Just include ntndk.h in hal.h instead of including 6 NDK headers (which turns into more than half of the NDK anyway since those headers include other NDK headers).
- Crashing and rebooting from KD now works properly.
svn path=/trunk/; revision=43380
2009-10-11 20:16:45 +00:00
|
|
|
xHalHaltSystem,
|
2007-12-15 16:18:49 +00:00
|
|
|
(pHalFindBusAddressTranslation)NULL,
|
|
|
|
(pHalResetDisplay)NULL,
|
[NTOSKRNL]
Revert r51017 that was reverting r51016.
In fact, it seems that cmlib assert error, whatever that eats randomly doesn't come from software issue inside ReactOS, but from a build issue.
Indeed, as you may see in the different tests I performed it shows that the same build produces the same failure, again and again. But, new build shows that there is no assert anylonger with that commit.
Don't ask me why or how it happens, I just don't get it.
But most of the time, it works, no one knows why ("as usual" (tm)). But it's cool.
Someone from BE team and/or buildslaves managers should take a serious look at this issue.
Just in case: if that commit re-hits cmlib assert, don't blame it immediatly, just commit something else, and see whether trunk is still broken.
But, as you can see in testman, we have now test results for r51016 ;-)
svn path=/trunk/; revision=51025
2011-03-12 12:56:36 +00:00
|
|
|
xHalAllocateMapRegisters,
|
|
|
|
xKdSetupPciDeviceForDebugging,
|
|
|
|
xKdReleasePciDeviceForDebugging,
|
|
|
|
xKdGetAcpiTablePhase,
|
|
|
|
(pKdCheckPowerButton)xHalReferenceHandler,
|
|
|
|
xHalVectorToIDTEntry,
|
|
|
|
(pKdMapPhysicalMemory64)MatchAll,
|
|
|
|
(pKdUnmapVirtualAddress)xKdUnmapVirtualAddress
|
2007-12-15 16:18:49 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/* FUNCTIONS *****************************************************************/
|
|
|
|
|
2009-10-29 19:58:41 +00:00
|
|
|
UCHAR
|
|
|
|
NTAPI
|
|
|
|
xHalVectorToIDTEntry(IN ULONG Vector)
|
|
|
|
{
|
|
|
|
/* Return the vector */
|
[HAL/NDK]
- Make Vector parameter in HalEnableSystemInterrupt, HalDisableSystemInterrupt and HalBeginSystemInterrupt an ULONG, not an UCHAR
[NDK]
- 64bit fixes for HANDLE_TABLE, KPROCESS, SECTION_IMAGE_INFORMATION, MMADDRESS_LIST, MMVAD_FLAGS, MMVAD, MMVAD_LONG, MMVAD_SHORT, MEMORY_DESCRIPTOR, MEMORY_ALLOCATION_DESCRIPTOR, LdrVerifyMappedImageMatchesChecksum
- KDPC_DATA::DpcQueueDepth is signed on amd64, unsigned on x86
[NTOSKRNL]
- Fix hundreds of MSVC and amd64 warnings
- add a pragma message to FstubFixupEfiPartition, since it looks broken
- Move portable Ke constants from <arch>/cpu.c to krnlinit.c
- Fixed a bug in amd64 KiGeneralProtectionFaultHandler
svn path=/trunk/; revision=53734
2011-09-18 13:11:45 +00:00
|
|
|
return (UCHAR)Vector;
|
2009-10-29 19:58:41 +00:00
|
|
|
}
|
|
|
|
|
- Stub out DbgKdWriteVirtualMemoryApi, DbgKdReadPhysicalMemoryApi, DbgKdWritePhysicalMemoryApi, DbgKdWriteBreakPointExApi, DbgKdRestoreBreakPointExApi, DbgKdSearchMemoryApi and DbgKdFillMemoryApi cases more properly.
- Fail on physical memory write like we do for read too.
- Don't handle OldVlm1/2 as they appear to be deprecated and unhandled in Windows.
- Implement HalHaltSystem to halt execution in a portable way. Default to xHalHaltSystem, a simple infinite loop, if we get called before HAL has initialized. Use this in KiBugCheckDebugBreak and the system shutdown handler instead of x86/AMD64/ARM intrinsics.
- Don't try to halt the CPU if KeBugCheck has been called 3 times or more -- if this happens, something has gone very wrong, and we shouldn't try to do anything special. Just loop infinitely.
- Fix KiBugCheckDebugBreak -- it shouldn't halt execution when called for the first chance as bugcheck callbacks have not been invoked at this point (nor has the BSOD been displayed). Use SEH to protect against a crash instead of checking KdDebuggerNotPresent as the debugger, if it is present, *could* disconnect while the trap is being handled. Also, don't halt execution if the debugger handled the breakpoint, just break again.
- Don't call MmMapIoSpace from HalpReboot! The reboot might take place at elevated IRQL (as high as HIGH_LEVEL if called from KeBugCheck), and thus can't use any Mm support routines. Use a PTE from the reserved HAL region and map it ourselves instead as done in the BIOS call code.
- Acquire the display ownership in HalReturnToFirmware in case the caller hasn't done so (as done in the KD reboot routine, for example).
- Just include ntndk.h in hal.h instead of including 6 NDK headers (which turns into more than half of the NDK anyway since those headers include other NDK headers).
- Crashing and rebooting from KD now works properly.
svn path=/trunk/; revision=43380
2009-10-11 20:16:45 +00:00
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
xHalHaltSystem(VOID)
|
|
|
|
{
|
|
|
|
/* Halt execution */
|
|
|
|
while (TRUE);
|
|
|
|
}
|
2010-03-08 20:37:24 +00:00
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
xHalEndOfBoot(VOID)
|
|
|
|
{
|
[NTOSKRNL]
Revert r51017 that was reverting r51016.
In fact, it seems that cmlib assert error, whatever that eats randomly doesn't come from software issue inside ReactOS, but from a build issue.
Indeed, as you may see in the different tests I performed it shows that the same build produces the same failure, again and again. But, new build shows that there is no assert anylonger with that commit.
Don't ask me why or how it happens, I just don't get it.
But most of the time, it works, no one knows why ("as usual" (tm)). But it's cool.
Someone from BE team and/or buildslaves managers should take a serious look at this issue.
Just in case: if that commit re-hits cmlib assert, don't blame it immediatly, just commit something else, and see whether trunk is still broken.
But, as you can see in testman, we have now test results for r51016 ;-)
svn path=/trunk/; revision=51025
2011-03-12 12:56:36 +00:00
|
|
|
PAGED_CODE();
|
|
|
|
|
2010-03-08 20:37:24 +00:00
|
|
|
/* Nothing */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
xHalSetWakeEnable(IN BOOLEAN Enable)
|
|
|
|
{
|
|
|
|
/* Nothing */
|
|
|
|
return;
|
|
|
|
}
|
[NTOSKRNL]
Revert r51017 that was reverting r51016.
In fact, it seems that cmlib assert error, whatever that eats randomly doesn't come from software issue inside ReactOS, but from a build issue.
Indeed, as you may see in the different tests I performed it shows that the same build produces the same failure, again and again. But, new build shows that there is no assert anylonger with that commit.
Don't ask me why or how it happens, I just don't get it.
But most of the time, it works, no one knows why ("as usual" (tm)). But it's cool.
Someone from BE team and/or buildslaves managers should take a serious look at this issue.
Just in case: if that commit re-hits cmlib assert, don't blame it immediatly, just commit something else, and see whether trunk is still broken.
But, as you can see in testman, we have now test results for r51016 ;-)
svn path=/trunk/; revision=51025
2011-03-12 12:56:36 +00:00
|
|
|
|
|
|
|
PBUS_HANDLER
|
|
|
|
FASTCALL
|
|
|
|
xHalHandlerForBus(IN INTERFACE_TYPE InterfaceType,
|
|
|
|
IN ULONG BusNumber)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
|
|
|
FASTCALL
|
|
|
|
xHalReferenceHandler(IN PBUS_HANDLER BusHandler)
|
|
|
|
{
|
|
|
|
/* Nothing */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
xHalInitPnpDriver(VOID)
|
|
|
|
{
|
|
|
|
return STATUS_NOT_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
xHalInitPowerManagement(IN PPM_DISPATCH_TABLE PmDriverDispatchTable,
|
|
|
|
OUT PPM_DISPATCH_TABLE *PmHalDispatchTable)
|
|
|
|
{
|
|
|
|
return STATUS_NOT_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
xHalStartMirroring(VOID)
|
|
|
|
{
|
|
|
|
PAGED_CODE();
|
|
|
|
|
|
|
|
return STATUS_NOT_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
xHalEndMirroring(IN ULONG PassNumber)
|
|
|
|
{
|
|
|
|
return STATUS_NOT_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
xHalMirrorPhysicalMemory(IN PHYSICAL_ADDRESS PhysicalAddress,
|
|
|
|
IN LARGE_INTEGER NumberOfBytes)
|
|
|
|
{
|
|
|
|
return STATUS_NOT_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
xHalQueryBusSlots(IN PBUS_HANDLER BusHandler,
|
|
|
|
IN ULONG BufferSize,
|
|
|
|
OUT PULONG SlotNumbers,
|
|
|
|
OUT PULONG ReturnedLength)
|
|
|
|
{
|
|
|
|
PAGED_CODE();
|
|
|
|
|
|
|
|
return STATUS_NOT_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
xHalSetSystemInformation(IN HAL_SET_INFORMATION_CLASS InformationClass,
|
|
|
|
IN ULONG BufferSize,
|
|
|
|
IN PVOID Buffer)
|
|
|
|
{
|
|
|
|
PAGED_CODE();
|
|
|
|
|
|
|
|
return STATUS_INVALID_LEVEL;
|
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
xHalQuerySystemInformation(IN HAL_QUERY_INFORMATION_CLASS InformationClass,
|
|
|
|
IN ULONG BufferSize,
|
|
|
|
IN OUT PVOID Buffer,
|
|
|
|
OUT PULONG ReturnedLength)
|
|
|
|
{
|
|
|
|
PAGED_CODE();
|
|
|
|
|
|
|
|
return STATUS_INVALID_LEVEL;
|
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
xHalLocateHiberRanges(IN PVOID MemoryMap)
|
|
|
|
{
|
|
|
|
/* Nothing */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
xHalRegisterBusHandler(IN INTERFACE_TYPE InterfaceType,
|
|
|
|
IN BUS_DATA_TYPE ConfigSpace,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN INTERFACE_TYPE ParentInterfaceType,
|
|
|
|
IN ULONG ParentBusNumber,
|
|
|
|
IN ULONG ContextSize,
|
|
|
|
IN PINSTALL_BUS_HANDLER InstallCallback,
|
|
|
|
OUT PBUS_HANDLER *BusHandler)
|
|
|
|
{
|
|
|
|
PAGED_CODE();
|
|
|
|
|
|
|
|
return STATUS_NOT_SUPPORTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
xHalSetWakeAlarm(IN ULONGLONG AlartTime,
|
|
|
|
IN PTIME_FIELDS TimeFields)
|
|
|
|
{
|
|
|
|
/* Nothing */
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
BOOLEAN
|
|
|
|
NTAPI
|
|
|
|
xHalTranslateBusAddress(IN INTERFACE_TYPE InterfaceType,
|
|
|
|
IN ULONG BusNumber,
|
|
|
|
IN PHYSICAL_ADDRESS BusAddress,
|
|
|
|
IN OUT PULONG AddressSpace,
|
|
|
|
OUT PPHYSICAL_ADDRESS TranslatedAddress)
|
|
|
|
{
|
|
|
|
KeBugCheckEx(HAL_INITIALIZATION_FAILED, 0, 0, 0, 0);
|
|
|
|
|
|
|
|
return FALSE;
|
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
xHalAllocateMapRegisters(IN PADAPTER_OBJECT AdapterObject,
|
|
|
|
IN ULONG Unknown,
|
|
|
|
IN ULONG Unknown2,
|
|
|
|
PMAP_REGISTER_ENTRY Registers)
|
|
|
|
{
|
|
|
|
PAGED_CODE();
|
|
|
|
|
|
|
|
return STATUS_NOT_IMPLEMENTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
xKdSetupPciDeviceForDebugging(IN PVOID LoaderBlock OPTIONAL,
|
|
|
|
IN OUT PDEBUG_DEVICE_DESCRIPTOR PciDevice)
|
|
|
|
{
|
|
|
|
return STATUS_NOT_IMPLEMENTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
NTSTATUS
|
|
|
|
NTAPI
|
|
|
|
xKdReleasePciDeviceForDebugging(IN OUT PDEBUG_DEVICE_DESCRIPTOR PciDevice)
|
|
|
|
{
|
|
|
|
return STATUS_NOT_IMPLEMENTED;
|
|
|
|
}
|
|
|
|
|
|
|
|
PVOID
|
|
|
|
NTAPI
|
|
|
|
xKdGetAcpiTablePhase(IN struct _LOADER_PARAMETER_BLOCK *LoaderBlock,
|
|
|
|
IN ULONG Signature)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
PVOID
|
|
|
|
NTAPI
|
|
|
|
MatchAll(IN PHYSICAL_ADDRESS PhysicalAddress,
|
|
|
|
IN ULONG NumberPages,
|
|
|
|
IN BOOLEAN FlushCurrentTLB)
|
|
|
|
{
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
VOID
|
|
|
|
NTAPI
|
|
|
|
xKdUnmapVirtualAddress(IN PVOID VirtualAddress,
|
|
|
|
IN ULONG NumberPages,
|
|
|
|
IN BOOLEAN FlushCurrentTLB)
|
|
|
|
{
|
|
|
|
/* Nothing */
|
|
|
|
return;
|
|
|
|
}
|