>Jonathan, you have succeeded (again) in turning a reasonable suggestion
>into a flamewar.  There's no excuse for that.

Charles,  most of your e-mail and interactions with me and the pmax
port have, to me, seemed abrupt, rude, inflammatory, and
condescending.  This one is no exception.   If you take objection
to my style, I would suggest that you examine your own style, both
in e-mail and CVS commits, first.

>But to respond to your poorly-formed points:

>1) The fact that the i386 port does `foo' does not mean that I either
>know or agree with it.  It also does not mean that I don't intend to
>change that behaviour.  It *hardly* means that I'm a hypocrite for
>suggesting that another piece of code shouldn't.

>2) Assuming a port supports it, `hz' can currently be changed in a
>compiled executable (along with `tick', of course), and the resulting
>kernel will work.  The NTP code breaks this.  If this is the case, 
>then there's hardly any reason for the `hz' variable at all, and it
>should be removed.

As I wrote at the time I incorporated the NTP code, I tried to allow
for two different cases:

	a) no NTP support, in which case kernels allow whatever
	   values for `HZ' (or none at all) and `tick', as they did
	   before NTP was incorporated.

	b) A kernel configuration-time option for kernel  PLL NTP support,
	   which is only available if HZ is defined, and moreover
	   defined to be a power of 2, so that David Mill's
	   PLL code works.

	which is, AFAIK, how _all_ kernel implementations of NTP
	precision timekeeping work.

>But I find this silly.  A variable-length shift is fast, can easily
>be implemented to support all the current values of `hz', and doesn't
>break the ability to change `hz' is a pre-built executable.  This seems
>like a win to me.

If what you want is to allow run-time selection of `hz' from the same
set of values that the NTP code currently supports for `HZ', why
don't you add it?  But that wasn't, as far as I could tell, what
you were asking.     (I also don't see what it has to do with the
PR I sent in, patching the  i386 port to use microtime.s instead
of machdep.c/microtime() when HZ _is_ defined, but defined to be 100,
which I did in response to a request from you to examine the  NTP code, 
which is what started this thread in the first place).


If you want to allow arbitrary values of HZ, as opposed to powers of 2,
then Mill's code needs a *divide*, not a *shift*.  Divides are
expensive.  Putting them inside hardclock() is  prohibitively
expensive, on some machines, in the opinions of people who've looked
at such things.   Arguing that ``shifts are cheap'' seems, to me,
an indication that you haven't examined the code well enough
to understand how it works.

As things stand, I incorporated Mill's code into the kernel with
essentially the functionality and configurability (i.e,. HZ
defined at compile time to be a power of 2 or some other special
values) as on other kernels that include NTP support.  That was
flexible enough for me, and (AFAIK) for everyone  else who uses
NTP.   As I said, if you want to redo the NTP extended-precision
timekeeping code and the PLL to remove that assumption, feel free.

It's beyond my interest, present level of expertise, and availability
of time to do so at the present.  If you want to do so, please do.