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