Re: CVS commit: src/sys/kern

[John Hawkinson <jhawk%MIT.EDU@localhost>]

Frank and Ben both point out the sysctl:

Ben Harris <bjh21%NetBSD.org@localhost> wrote on Sun,  6 Aug 2006
at 11:42:27 +0100 in 
<Pine.LNX.4.61.0608061135490.15656%soup.linux.pwf.cam.ac.uk@localhost>:

> 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