Re: hw.cpufamily vs ASP vs machine.h
Re: hw.cpufamily vs ASP vs machine.h
- Subject: Re: hw.cpufamily vs ASP vs machine.h
- From: Stephane Sudre <email@hidden>
- Date: Fri, 2 Mar 2007 11:08:54 +0100
On 2 mars 07, at 02:15, Michael Smith wrote:
On Mar 1, 2007, at 12:05 PM, email@hidden wrote:
Well, I took a different road. I don't want to rely on system_profiler
for additional reasons (one of them is the fact that the -xml
SPHardwareDataType does not work on Mac OS X 10.2, another one could
be
not to use a tank (slow and too much information) to kill an ant).
For PowerPC, I still use the old code if the OS is too old. For i386,
I
use sysctl with the machdep.cpu branch and another one to get the
family and to know whether it's a multi-core or mono-core CPUs.
So in the name of supporting 10.2, you took a path which will not work
on future versions of the OS instead, despite advice from several
Apple folks?
???
I use the old code on old OS versions. I don't expect 10.2 or 10.3 to
see an update changing anything there.
For 10.4 and later, I use new code based on new sysctl values.
If you give a look at
/System/Library/SystemProfiler/SPPlatformReporter.spreporter/Contents/
MacOS/SPPlatformReporter, you will be able to see that sysctl is also
the solution used by Apple.
Additionally, the issue I could see is not with future version of the
OS IMHO, it's with future Intel chips.
I have to ask, why bother posting here in that case?
Is there a law making it mandatory to use a solution recommended on a
mailing-list? Isn't it possible to weight the options and use the one
that looks better in your own case?
As for killing things with a tank; I fear your sense of proportion is
a bit mis-calibrated. Executing a tool and capturing its output for a
one-off operation is a relatively cheap thing to do; the system
expects (even encourages) tools to be used in this fashion.
Well, let's consider that I go with system_profiler only:
1. The -xml SPHardwareDataType option is not working on 10.2 which I
need to support. -xml is but when I run this on a PowerMac G4 450 MP
10.2.8 (768 MB RAM), it takes 1 minute to return all the information
and 99.9999% of them are useless. The old code does this in real time.
And I need to get the result in real time.
2. I would need to parse the output.
3. I can't be 100% sure system_profiler is on the system. I would have
to add some code to check for this and have a spare path for it (for
instance, the code I'm using).
4. I would have to launch an external tool.
5. Some external tool such as 'ps' makes me think you can't rely on
external tools not evolving.
So basically, this solution would be way slower on some systems, takes
more code and makes me rely on an external tool.
Anyway, I will file an enhancement request for an API to get this
information without having to use system_profiler.
My $0.02
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden