Recent trends in the codebase size

[Eric S. Raymond]

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>