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

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.

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.

Now, could you please reply to my suggestion in a constructive manner?