> The (classical) question is: should I hand out the timestamps as a seperate
> device, run the standard nntp deamon to use them, which in turn calls the
> appropriate kernel functions to adjust the time?
> 
> Or should I shortcut this and adjust the time right inside the kernel, without
> any device and userland daemon?

I think you'd be far better off to go with the device, including both
the timestamp and the result of an in-kernel call to microtime() taken
as close to the timestamp arrival as possible.  This leaves you with
the option of either doing an ntp reference clock driver to use the time,
or just writing a small daemon to compute time offsets and adjust the
kernel clock accordingly.  I'd note that the fact that it is a small
machine matters little in either of these situations; the only latency
which matters at all here is the latency (jitter, actually) between
timestamp arrival and the microtime() sample, if the latter is done
in the kernel the remaining work can be done anywhere.

The reason I think you're better off with the device is that the kernel
PLL thing, while it looks seductively generic, actually has more dependence
on it being xntpd which supplies the adjustments than meets the eye (this
is part of the reason I'm not fond of that code being in the kernel).  If
you do the device you retain the option of either using xntpd, which will
give you the best result, or writing a minimal thing to just compute offsets
and shove the result back into the kernel, which will give you results
which are in no way inferior to what you'd end up with with an all-kernel
implementation.

Dennis Ferguson