>> +    case TIOCDCDTIMESTAMP:
>> +            com->sc_dcd_timestamping = 1;
>> +            *(struct timeval *)data = com->dcd_timestamp;
>> +            break;
>
>On the first invocation, you get a bogus timestamp.


Yes, so it does.  But that's the API that xntpd expects. 

It does an initial TIODCDTIMESTAMP and ignores the return value from
the initial timestamp call.  Thereafter, the N'th TIODCDTIMESTAMP call
requests that the kernel timestamp the next DCD pulse, and returns the
N-1'th timestamp.  (At least that's how I read it.)

CGE actualy brought up this very same point last month.

Back then, I agreed with CGD, that a better API would be nice. But
this is the defacto standard API used by FreeBSD, Linux, and xntpd
(3.x) and ntpd (4.x).    I don't recall you saying anything about that?

If you want to invent a new ioctl interface with two distinct ioctls,
  (a) an ioctl to  tell the kernel to latch DCD pulses as PPS timestamps
  (b) return the most-recent timestamp

Then go ahead, everyone here would be glad, but AFAICT we *still* need
this kludgy interface for xntpd.  

That is, we need it until and unless we can persuade Harlan Stenn to
to buy into the new API, which means getting FreeBSD and Linux and now
Solaris to do so, too.

If you have a different angle on that discussion than what was
discussed last month, I'd be glad to hear it, but I genuinely thought
we'd reached a consenus on that issue.  Are there other bugs?


I'd left a similar patch for the MI zs driver up to Bill Studenmund,
but Bill's oral defense kinda got in the way.