fallenpega...@gmail.com said: > Is there a reason to keep dumbclock? Maybe it exists as a starting > framework for when someone wants to write a new clockdriver?
It's not good for much more. 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 won't complain if it goes away. ---------- > 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? Ages ago, I looked into writing a parse driver. I didn't get very far. Maybe because I didn't try very hard. Maybe because the hardware I was working with wasn't a good fit. Maybe because I got it going as a real driver and lost interest before I went back to work on the parse driver. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
