Why is it that the people with the strongest opinions never actually
say anything until I propose to commit code to the tree, with a deadline--
and when I do that, _I'm_ the bad guy? ;)


>> Maybe there's a better way. But I thought handling the old ioctl API
>> inline in the chipset-level code "while we're in there" was a cleaner option.

>Looking at the code, that may in fact be true. 

yup, I'm not a complete idjut, despite what some people seem to think;).
I'll wait to see if anyone has better ideas, and do the old API inline
only if nothing better is suggested.


> (Even so, you still
>have to implement the 'good' bits.)

Yes. As I said 3 weeks ago, that'll be done, if it's really necessary.
Jason and you both want it: that's good enough for me.  (sigh. If
Jason had bothered to say something 3 week ago, itd be done by now.)

But we still need the `bad' bits used by the existing code.


>I actually wonder if a more general facility is in order and/or
>useful, e.g. allowing timestamping to be enabled on one of:
>
>        (1) "DCD events"
>
>        (2) "character interrupts"
>
>        (3) (other events which I can't think of right now),


Please, not here.  This is purely for disciplining the system clock.
it's also where calls to hardpps() should go, if we stick with
in-kernel clock disciplining.  I think more general timestamping (and
management) is a separate isssue.


Besides, that's basically what the _other_ thread (CHU clock: time
pips from Canada, sent on shortwave as 300-baud modem tones) was
about.  CHU needs a timestamp on every char: there's a line discipline
which convolutes the timestamps on each byte of a ten-byte sequence to
approximate where the true second tick happened.

Here, I think the right choice is not to do anything at all, util
there's a multibyte interface betwen chipset level code and the line
discipline.  Then we add a kernel API which does "enqueue N bytes for
the linedisipline, or drop all N bytes".  Then we can stuff packets of
"one data byte + timestamp" across that boundary atomically, without
any risk of losing frame boundaries.  That can handle handles some
other special cases (timestamped mouse events?) too.

So, specifically, I'm _not_ proposing to copy the existing 1980s NTP
code or the FreeBSD per-char-timestamp code, or to pull either one
into the NetBSD tree. OK?