Subject: Re: non-PPS clock signals (CHU)
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
List: tech-kern
Date: 03/30/1998 13:26:58
>	1) add a multibyte path from  serial drivers up to
>	   the line discipline. We want that anyway, so its going to happen.
>
>	2)  Establish a software convention, that the tty_clk
>	    and tty_chu line disciplines always take five-byte
>	     ``packets'' from the lower-level serial driver.
>
>	3)  add ioctls to switch the lower-level driver
>	    into and out of a mode where it generates the
>	     data-byte-plus-timestamp  values.

So, I've thought about this all weekend, and I've stared at the code.
And after much thought ... I really think Charles Hannum is right.
Doing 1) would really require much screwing with the current com
driver ... to the point where I think it would affect other uses of it.
Writing a new driver would be better, if you really wanted to do that.
But I'm not sure that's necessary :-)

>Yup.  In fact you could have the hard-interrupt routine grab each
>char, timestamp it, and stuff both the char and each byt eof the
>timestamp into the softtty() loop. The problem here is, what happens
>if you lose the implicit framing boundaries (character drop, or worse,
>overflowing the line-discipline queue).  How does the line discipline
>even notice, let alone get back in synch?

Well, with CHU it's not a problem ... because the line discipline already
knows how to deal with it.  Depending on the radio signal, you can just
get random noise (which the CHU line discipline knows how to filter out).
This would also destroy the "frame" concept.  As for losing framing
with the data bytes and the timestamp, it seems like this would be
very difficult to happen.  If the com ring buffer fills up (unlikely,
since it's 2048 bytes and this is 300 baud), you could just drop the
data byte and the timestamp.

So I think that the "right" thing to do is stuff the timestamp in the
data stream at hard interrupt time, like the tty_clk discipline does.
That way the tty_clk discipline could be made much simpler, and you
don't have to do any weird timestamping stuff for tty_chu.  I'll try
that sometime this week or next and see how it goes.

--Ken