<div dir="ltr">My inclination is that when more clock types show up, they get a driver running in it's own process space, and exporting a SHM buffer.<div><br></div><div>The problem with covering existing drivers to that is...  testing them.</div><div><br></div><div>..m</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Jan 29, 2017 at 10:49 PM Eric S. Raymond <<a href="mailto:esr@thyrsus.com">esr@thyrsus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hal Murray <<a href="mailto:hmurray@megapathdsl.net" class="gmail_msg" target="_blank">hmurray@megapathdsl.net</a>>:<br class="gmail_msg">
> It's not clear that there is any good way to have a starting point reference.<br class="gmail_msg">
>  If you give examples of all the possibilities, it will be too complicated.<br class="gmail_msg">
> You can start with an existing driver.  That's easy if you already know your<br class="gmail_msg">
> way around, but there is likely to be a lot of code that you have to skip<br class="gmail_msg">
> over.<br class="gmail_msg">
<br class="gmail_msg">
I agree, this is a real problem.  I have an item on my long-term to-do<br class="gmail_msg">
list to rewrite the generic-driver HOWTO so writing parse templates<br class="gmail_msg">
becomes easier. And maybe apply some of GPSD's tricks to make a mode<br class="gmail_msg">
that tries to autoadapt.<br class="gmail_msg">
<br class="gmail_msg">
That's kind of blocked on having a device that exercises that driver, though.<br class="gmail_msg">
I want to know that it actually still works before I put in the effort.<br class="gmail_msg">
<br class="gmail_msg">
> I won't complain if it goes away.<br class="gmail_msg">
<br class="gmail_msg">
It's gone.<br class="gmail_msg">
<br class="gmail_msg">
> > 2. If it were up to me, nobody would ever write an old-school refclock<br class="gmail_msg">
> > again.  Makes more sense to write a parse template for the generic driver.<br class="gmail_msg">
> > You get more code re-use that way.<br class="gmail_msg">
><br class="gmail_msg">
> I think that only works for hardware that fits the model.  There is a lot of<br class="gmail_msg">
> stuff that doesn't.  Could you fit a SHM driver in there?  How about<br class="gmail_msg">
> JSON/GPSD?<br class="gmail_msg">
<br class="gmail_msg">
You're right, of course, and a POSIX-compliant shared-memory driver is<br class="gmail_msg">
exactly the exception I should have thought of.<br class="gmail_msg">
<br class="gmail_msg">
My defense is that I was thinking of actual hardware clocks.  Which do<br class="gmail_msg">
seem in general to all be very alike in what they emit.  I'm pretty sure<br class="gmail_msg">
that several of the existing srivers (at least spectracom and trutime,<br class="gmail_msg">
probably more) do in fact fit the model.<br class="gmail_msg">
--<br class="gmail_msg">
                <a href="<a href="http://www.catb.org/~esr/" rel="noreferrer" class="gmail_msg" target="_blank">http://www.catb.org/~esr/</a>">Eric S. Raymond</a><br class="gmail_msg">
</blockquote></div>