Subject: Re: CVS commit: src/sys/kern
To: Frank Kardel , Ben Harris <bjh21@netbsd.org>
From: John Hawkinson <jhawk@MIT.EDU>
List: source-changes
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.4.61.0608061135490.15656@soup.linux.pwf.cam.ac.uk>:

> 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
	unexpectedly.
#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.

Thanks.

--jhawk