Subject: Re: CVS commit: src/sys/kern
To: Frank Kardel , Ben Harris <email@example.com>
From: John Hawkinson <jhawk@MIT.EDU>
Date: 08/06/2006 09:20:37
Frank and Ben both point out the sysctl:
Ben Harris <bjh21@NetBSD.org> wrote on Sun, 6 Aug 2006
at 11:42:27 +0100 in <Pine.LNX.firstname.lastname@example.org>:
> I was a bit uncertain about this, but if you want all the digits you can
> always ask sysctl:
> fastnet:~$ sysctl kern.timecounter.choice
> kern.timecounter.choice = iomd_timer0(q=100, f=2000000 Hz) clockinterrupt(q=0, f=100 Hz) dummy(q=-1000000, f=1000000 Hz)
Unfortunately, this does not allow you to perform an after-the-fact
analysis of changes without advance preparation or additional
instrumentation. (I don't maintain that this is a likely sort of thing
to do, or that most change timecounters often enough for it to matter
[or do they?], but I am annoyed at the loss of flexibility for no
apparent material gain.)
> In a similar way, we approximate disk capacities when printing them at
> boot time, and assume that anyone who needs the precise number of sectors
> will use disklabel.
I don't think this is a fair comparison at all:
#1 Most users know their disk capacities already.
#2 Disk capacities don't have the potential to vary
#3 Disk capacity is a number directly usable by most users, and
for which the low-order bits are insignificant. Most users
could care less about clock frequency, and some may find the
low-order bits of utility.
Anyhow, regardless, I don't think this deserves
13 messages to this list. :(
Some other reasons to go back:
i) Gratuitous difference from FreeBSD
ii) Cosmetic changes should not hamper flexibility. It's hard to
predict exactly when you will find a number useful (which is
why we add so much instrumentation to software!).
iii) I think it sets a bad precedent to go around humanizing
numbers without a lot of care and thought.