Upcoming feature freeze
hmurray at megapathdsl.net
Fri Aug 25 05:42:46 UTC 2017
> #55: ntpd refclock GPSD_JSON just stops working.
I haven't noticed any troubles.
> If any of you have an interest in saving this driver, step up now and fix
How important is supporting gpsd on systems without SHM?
I think we need the concept of stability to be associated with various
features. There should be a way to ship something without a promise of long
term support or that it will run on all systems or that all combinations of
options have been tested or ...
This whole area needs a lot of thought and work. I assume that is on the
post 1.0 list.
Is anything written down anyplace? Where? How does SHM/JSON interact with
the great refclockd proposal?
We could fix the ntpd side of the SHM interface to be read only. That would
let multiple readers listen to the same source so you could fire up shmmon
while ntpd was running. I think this would solve a protection problem.
Some systems don't have SHM. Do we have a list of those systems? Do we need to support external refclocks on those systems? Are we using POSIX SHM? (How many SHM variants are there?)
Would you be happy if we threw away the current code and you started from scratch? Would it help if the JSON interface was NTP centric rather than GPSD centric? Maybe we should make a JSON-JSON translator to go between gpsd and ntpd.
It would be nice if there was a clean interface for external drivers. I assume that each current driver would turn into a stand alone program that talked to ntpd via some new/wonderful interface.
These are my opinions. I hate spam.
More information about the devel