[ntp:hackers] u-blox reference clock driver

[MLewis]

Achim,

On 20/08/2018 1:35 PM, Achim Gratz via devel wrote:
> .. Unless I'm missing something, your implementation would do 
> something I proposed a few weeks ago, namely skip dealing with PPS in 
> altogether and correlate kernel and GPS time via timestamping on the GPS. 
Exactly! It's been on my todo list for a couple of years, but I wasn't 
motivated to get into a LKM to get to kernel space to make it 
worthwhile. Although I suspected that even from user space, the result 
would be better than some PPS.

>> A cycle of triggering timemarks (one cycle per second) can be initiated:
>> - by the PPS so it's aligned with GPS UTC, or
> Traveling through two device drivers to get the PPS echo out doesn't
> seem appealing to me.
Which is why I'm ignoring the PPS driver.
Trivial to include PPS in this LKM.
This allows the timemark triggering to be aligned to GPS TOS.
The benefit of being able to align the timemark triggering to PPS, hence 
TOS in the GPS module, is that we may find different jitter depending on 
when within a second the timemark is performed. Until we have data, we 
won't know.

> You can actually drop the PPS in this case, as it will provide no benefit.
Agreed. Except possible benefit with alignment, as described above.

>> I'm held up deciding on the method of sending messages for each
>> Trigger Timestamp from the kernel module back to user space.  Looks
>> like it should be a socket.
> I'd model it after the PPS API, just create two devices for each
> timemark generator that provides the sequence number and kernel times
> for assert and clear edges.  There might be another pair of devices that
> provides the measurement results in the same form, but I'd start out
> doing that in userspace as each device will format these differently.
> This task sounds like a good excuse to use the BPF in-kernel VM.
>
>
> Regards,
> Achim.
I've already got single or dual timemarks rise & fall coded, along with 
PPS or system time TOS alignment.
I see it as a stream of timestamp messages returning to user space.
Multiple LKMs is worth considering. I'll have to work through the 
implications.
It should be simple enough to take mine and split it up.

Michael