Re: Using processor_info
Re: Using processor_info
- Subject: Re: Using processor_info
- From: Jim Magee <email@hidden>
- Date: Fri, 15 Aug 2003 11:02:43 -0400
On Friday, August 15, 2003, at 9:31 AM, Brad Post wrote:
I'm trying to get some information on the processor using the mach
interfaces, and getting some weird results and wondering if anyone
knows
why?
The function I am using is as follows:
kern_return_t get_host_processors(void)
{
kern_return_t result;
processor_array_t procArray;
mach_msg_type_number_t procCount;
processor_basic_info_data_t procInfo;
mach_msg_type_number_t infoSize;
host_t thisHost;
host_priv_t thisPrivHost;
unsigned long index;
thisHost = (host_t) host_self();
thisPrivHost = (host_priv_t) host_priv_self();
/*
* Host Processors
*/
result = host_processors(thisPrivHost, &procArray, &procCount);
if (result == KERN_SUCCESS)
{
for (index = 0; index < procCount; index++)
{
infoSize = PROCESSOR_BASIC_INFO_COUNT;
result = processor_info( procArray[index],
PROCESSOR_BASIC_INFO,
&thisHost,
(processor_info_t) &procInfo,
&infoSize);
}
}
return (result);
}
For some reason the call to processor info always returns 0, and a
valid
infoSize, but all the data is always nil.
You don't provide much "environment" information. But let me guess.
You're calling this from a KEXT. Right? Actually, It's not that much
of a guess, since host_priv_self() doesn't exist at user-space. While
many Mach APIs work identically in and out of the kernel, that isn't
true for all of them. Specifically, in-kernel interfaces that process
or return out-of-line memory (or out-of-line arrays of ports) differ
from their user-level counterparts.
In this case, since host_processors() returns an out-of-line array of
processors to user-space, but processors are represented by ports at
user-space, what you are actually getting is an array of processor port
pointers, NOT an array of processor pointers (due to a limitation in
the MIG IDL tool that doesn't allow it to do on-the-fly outtrans
conversions on arrays of object references, the routine does the
conversion to ports itself). You can't take the resulting port
pointers and just feed them into the processor_info() API. You're
going to get wrong information, potentially corrupt the port data
structure, and/or panic your system.
You'd have to convert each port reference (send right) back into a
processor reference and then pass it in. That's kind of cumbersome, as
it requires you to call convert_port_to_processor() on each processor
port, use the results in processor_info() and then potentially
deallocate the processor reference you used (but in this specific case,
since processors are live-forever objects, the kernel doesn't bother to
track references so there is no deallocation necessary). And then
don't forget to kfree() the memory that housed the port array (yep,
in-kernel port arrays are transferred in kalloc memory, not vm_allocate
memory).
There is a host_processor_info() call that avoids the port/processor
reference issues by returning an out-of-line array of processor info
structures. But, as I stated before, out-of-line arrays of data are
also treated differently (and, therefore, can't be accessed directly)
from within the kernel.
Having to embed all this Mach implementation knowledge in you KEXT is a
pain for you and bad for us (if we even want to correct the MIG issue
in the future or change the memory allocator to match user-space).
That's why we don't really encourage calling random Mach APIs from
KEXTs.
Most of the information you are likely after is available from either
IOKit registry/device tree interfaces, or (in Panther/Darwin 10.7) from
a new sysctl() interface that is symmetric between user-space and
kernel space. Those might be better places to look for this info. If
you must use the Mach APIs, processor_info(current_proc()) at least
doesn't leave you with all the issues of host_processors().
--Jim
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.