From owner-freebsd-hackers  Fri Mar 15 10:27:58 2002
Delivered-To: freebsd-hackers@freebsd.org
Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84])
	by hub.freebsd.org (Postfix) with ESMTP id DD42E37B405
	for <hackers@freebsd.org>; Fri, 15 Mar 2002 10:27:52 -0800 (PST)
Received: from pool0371.cvx22-bradley.dialup.earthlink.net ([209.179.199.116] helo=mindspring.com)
	by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #1)
	id 16lwQX-0007Z5-00; Fri, 15 Mar 2002 10:27:42 -0800
Message-ID: <3C923D0A.2259D49F@mindspring.com>
Date: Fri, 15 Mar 2002 10:27:22 -0800
From: Terry Lambert <tlambert2@mindspring.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Josh Paetzel <friar_josh@webwarrior.net>
Cc: Matthew Emmerton <matt@gsicomp.on.ca>, hackers@FreeBSD.ORG
Subject: Re: Interesting sysctl variables in Mac OS X with hw info
References: <Pine.BSF.4.21.0203131636280.70491-100000@InterJet.elischer.org> <006601c1cb06$b9f07370$1200a8c0@gsicomp.on.ca> <3C902B36.4D4EB8E@mindspring.com> <20020315100853.P287@twincat.vladsempire.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-hackers.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-hackers>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-hackers>
X-Loop: FreeBSD.ORG

Josh Paetzel wrote:
> This is a perfect example of, "Just because you can do something,
> doesn't mean you should."
> 
> I wouldn't see anything wrong with grabbing the clock frequency of the
> first cpu in the system and noting in the man page that if you have
> multiple cpus and you aren't running them at the same frequency, then
> the reported value is applicable only to the first cpu.
> 
> This would save a ton of time in implementing Jordan's ideas, at the
> cost of not being able to deal correctlywith a situation that
> (hopefully) isn't too common in the field.  The other less tangible
>  disadvantage to my suggestion is that it takes us one step further in our
> single-cpu-centric userland, ala top, uptime, and so forth only
> displaying stats for "one" cpu.

Incorrect information is always worse than no information.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message