Jonathan, I haven't been ignoring you because you disagree with me.
I've been ignoring you because I'm SICK AND TIRED of you flaming the
Hell out of me about things that you are clearly wrong about.

Let's look at some easily verifiable facts, shall we?

1) It is a fact that any interrupt handler which calls wakeup() *must*
   be blocked by splclock().  Even if this wasn't documented (which it
   is), it should be obvious given that hardclock() mucks with run
   queues, and you'd therefore introduce a race condition.  Ergo, if
   the serial interrupt interrupt handler calls the line discipline
   (and I include both tty_chu and tty_clk here, because both of them
   call wakeup() from their input routines), then the serial interrupt
   handler *must* be blocked by splclock().  There simply isn't any
   room for disagreement here.  And I'll note that FreeBSD doesn't do
   this either.

2) You state you were taking measurements with NetBSD 1.2E and
   1.3_ALPHA.  In fact, there is a known bug in those versions that
   affects interrupt latency when other I/O is happening.  This bug
   was fixed before the 1.3 release.  I believe, therefore, that your
   alleged measurements are actually irrelevant.

Now, anyone with even a shred of clue can see that having the serial
interrupt (and therefore the DCD timestamping) blocked by splclock()
would substantially increase jitter.  It is therefore very bad for PPS
signals, which is exactly what you want to implement.  I conclude from
this that your suggestions were poorly thought out, based on an
obvious lack of understanding of (Net)BSD interrupt handling, and at
least this one should not be implemented.

Frankly, I find it both amusing and outright disgusting that you
challenge me on such an issue, given the number of times you've said
that you `just don't understand' interrupt priorities.


And now, since I expect nothing other than flames from you, I shall go
back to studiously ignoring your mail.