Paul Gofman pgofman@codeweavers.com writes:
On 5/22/20 19:50, Alexandre Julliard wrote:
Paul Gofman pgofman@codeweavers.com writes:
Signed-off-by: Paul Gofman pgofman@codeweavers.com
dlls/ntoskrnl.exe/ntoskrnl.c | 12 +++++++++++ dlls/ntoskrnl.exe/ntoskrnl.exe.spec | 1 + dlls/ntoskrnl.exe/tests/driver.c | 31 +++++++++++++++++++++++++++++ include/ddk/wdm.h | 1 + include/winnt.h | 2 ++ 5 files changed, 47 insertions(+)
diff --git a/dlls/ntoskrnl.exe/ntoskrnl.c b/dlls/ntoskrnl.exe/ntoskrnl.c index aa71b7c48c..830608ce50 100644 --- a/dlls/ntoskrnl.exe/ntoskrnl.c +++ b/dlls/ntoskrnl.exe/ntoskrnl.c @@ -2385,6 +2385,18 @@ KAFFINITY WINAPI KeQueryActiveProcessors( void ) return AffinityMask; }
+ULONG WINAPI KeQueryActiveProcessorCountEx(USHORT group_number) +{
- TRACE("group_number %u.\n", group_number);
- if (group_number && group_number != ALL_PROCESSOR_GROUPS)
- {
FIXME("group_number %u not supported.\n", group_number);return 0;- }
- return NtCurrentTeb()->Peb->NumberOfProcessors;
+}
You should probably use GetActiveProcessorCount(), so that it will automatically start working when that one is implemented.
My understanding was that as a general rule we don't want to rely on kernel32 / kernelbase functions in ntoskrnl.exe (I guess ideally it should not be loaded at all in kernel mode driver process). If that is not the case, should I then return NtCurrentTeb()->Peb->NumberOfProcessors from GetActiveProcessorCount()?
No, it's OK to use kernel32, we use many other dlls too.
I don't see a reason to change GetActiveProcessorCount(), admittedly it's not doing this the most efficient way, but it's not the correct implementation anyway.