Recent trends in the codebase size

[Mark Atwood]

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 <esr at thyrsus.com> wrote:

> Hal Murray <hmurray at 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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170130/1e04fa96/attachment.html>