It seems to me we're both saying that
   a) the "clean" ioctl API for PPS sampling is worth having
   b) For old obsolete radioclocks that dont' do PPS (and therefore need
      timestamps  on every char),  ioctls for timestamping aren't
      useful: that should be done as a line discipline
   c) there's no known application for more general `timestamping'.

Is that right?


>>My take is that you'd probably want two distinct _separate_ timestamps
>>here: one for the data stream and one for the DCD edge(s).

>If this *is* the case, you would probably want a separate mode (the
>virtual equivalent of a line discipline) for stamping input data
>-- but I had gathered that non-PPS clocks did not have a DCD (or
>DTR or whatever other pin you might need because of serial port
>weirdness) stamp, so that the situation was always one or the other,
>never both. 

It should be "never both" for a single clock.  But some weirdo (like
me) might hook up a homebrew non-PPS clock to figure out the time to
the nearest second, and a cheap handheld GPS box wiwh a PPS signal to
figure out exactly _when_ the second boundaries fall.  But that's no
sweat: at the NTP level, configure two clocks.  Each xntpd clock
driver issues the right ioctls and the Right Thing happens, even if
they're on the same physical serial chip (modulo exclusive opens).

>You misunderstand: GTSTAMP does not retrieve the time stamp itself.
>Rather, it retrieves the current "time stamp mode" setting (so that
>you can get the mode, set a new mode, run for a while, and restore
>the old mode).

But my take is that PPS is _not_ really a timestamp. It's sampling the
phase error between the system clock and an external reference clock.
That this uses the same format as a timestamp is more or less
accidental. In a couple of years, we could want to use CPU cycle
counts instead, at least on a uniprocessor.

I just don't see the rationale for overloading the "Sample PPS phase
offset" interface to a ``more general'' timestamping API.

FreeBSD has  two ioctls:
#define	TIOCTIMESTAMP	_IOR('t', 89, struct timeval)	/* enable/get timestamp
						 * of last input event */
#define	TIOCDCDTIMESTAMP _IOR('t', 88, struct timeval)	/* enable/get timestamp
						 * of last DCd rise */

Each of these has its own flag and its own timeval field in the serial
device softc.  they both have the same overloaded semantics: turn on
timestamping and fetch the most-recent timestamp, if any.

The patch I put on the FTP site (fixes a couple of typos in the
emailed patch) replaces TIOCDCDTIMESTAMP with

     TIOCGTSTMP		/* get PPS timestamp state */
     TIOCSTSTMP		/* set PPS timestamp state */
     TIOCFETCHLASTTSTMP	/* fetch most recent PPS timestamp */

(or will, as soon as i change the names to match Chris Torek's
suggestion) and has backwards compatible hacks for TIOCDCDTIMESTAMP.
And since

  a) no-one has suggested an application for TIOCTIMESTAMP-style
     per-char timestamps;

  b) there's general agreement that for NTP applications,
     per-char timstamping  should be an ldisc (or moral equivalent);

  c) even if we overload the API to handle N kinds of timstamping,
     there still need to be N timestamp fields in the softc,
     and N ioctls (or an ioctl with internal dispatch) to get 
     each of the different kinds of timestamps;

Why overdesign the PPS get-state/set-state ioctl()s to handle it?  I'd
prefer to keep PPS phase-error sampling separate from any ``more
general'' timestamping.  If you see a good reason, OK, but to me it's
starting to look like kernel bloat.

>needs a name -- GETLASTSTAMP?) to get the most recent timestamp
>(which, in the brave new POSIX world, should now be a timespec
>rather than a timeval).

I was using FETCHSTAMP. FETCHLASTSTAMP maybe?

Timekeeping to greater than than 1-usec accuracy is possible with
today with PC hardware, GPS, and temp-controlled xtal.  As soon as CPU
clock rates exceed 1Ghz we'll want more resoution than even a
timespec.  That's what I was getting at earlier.


>I have no strong opinions on how to implement per-character time
>stamps, although line-discipline- or virtual-equivalent-wise,  >an
>interleaved data stream of the form <character,timestamp> (where
>each of those two components is a fixed number of bytes) might be
>the best method.  

uh, that's exactly what I proposed yesterday (and 3 weeks ago too) but
built on top of a multibyte interface between drivers and linediscs
That's why, two emails back, I said these were really completely
separate issues.  What's your take on that now?


>If per-character time stamping were a line discipline, that mode
>would be set with TIOCSETD (and be independent of any PPS-style
>stamping).

Yup, and AFAIk that's what Ken Hornstein is actively purusing.