>If you're going to do this with a serial line, I suggest that you just
>write a completely separate special-case driver that does what you
>need.

The thing is, writing a serial driver (and doing a good job of it) is
fairly non-trivial.  People smarter than me have spent a lot of time
working on the serial driver, and it shows.  To throw that all away and
come up with a completely new driver when the current com driver works
just fine and does almost everything I would need to do seems like a
big waste of time.  It's not that I mind doing hard work, but if
someone else has done the hard work already, why not use it?
Especially when someone has already gone to all of the trouble to make
it MI, work on the alpha, etc etc.  I suppose I could just copy the com
driver and call it com_chu .... but would people really want that?

It seems like a good first step would be to put the CLK_CHU line
discipline in place, without any special speed hacks at all, and see
how well it works.  Then you could decide based on your clock
accuracy what kind (if any) sort of changes you'd need to do to
improve things.

On the "improve accuracy" front ... it seems that if you put the
timestamping directly into comintr(), you'd get about the most accurate
measurment of character time that would be possible, even with a
special driver (that's assuming I understand the way the interrupt
system works, and that could be wrong :-/).  Before anyone else says
anything ... of course this hypothetical code would be appropriately
#ifdef'd to not affect the normal user in the least bit.  And of course
you could toggle this on and off via an ioctl() or whatever.  I think
you could do the same for the MI zs driver fairly easily.

Would there be anything wrong with that?  It seems to me that it would
be relatively few lines of code, and doesn't require any
restructuring.  Admittedly, you could (like you said) reduce the jitter
even more with a special driver because of the way soft interrupt
processing is done, but at 300 baud (assuming you aren't doing a lot of
other serial I/O) is it going to be that much of a problem?  And
considering that (in the CHU case) the signal you're receiving is only
good to approximately 1ms, will you really introduce that much jitter
that it would affect anything?

BTW, I have enjoyed almost all the discussion on this topic; it has
been very interesting, and I've learned a lot (I do wish the people who
keep saying, "you're going to kill serial performance for everybody!"
would note that I've said that this hypothetical code would be #ifdef'd
in nearly _every_ piece of email I've sent on this subject.  Sigh.)

I hope that everyone knows I wasn't trying to steal Jonathan's thunder
on the subject of his TIODCDTIMESTAMP patch; Jonathan and I had been
talking off-line about NTP issues for a while, he sent in his email,
and that made _me_ think about some NTP stuff that had been kicking around
in my head for a while, so that's why I sent my note out soon after.
I agree that the things I'm suggesting (slowing down serial performance
for everyone :-) ) is completely separate from his TIOCDCTIMESTAMP
work.

--Ken