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 | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.