[ntp:questions] Re: bc637PCI-U Reference Clock Driver
hundoj at comcast.net
Sat May 7 14:04:41 UTC 2005
David L. Mills wrote:
> Actually, the TPRO driver (12), Bancomm (16) and TT560 (41) drivers
> very similar, since all they do at each poll event is suck up some
> registers, reformat as necessary, and let the refclock interface do
> rest. I may have the last TPRO interface in the world and all my SBus
> machines have died, so probably driver 12 should be retired. Driver
> is in active use at the UNSO sites now. I don't know how many TT560
> boards there are out there; I have one and I suspect TrueTime sold a
> bunch of them now probably on EBay.
> I think it only makes sense to combine the drivers if the result did
> need to be told which device is connected other than perhaps to
> configure the device name and/or link. For the combined Spectracom,
> Truetime and ACTS drivers, you don't need to do anything except
> the link.
> In any case, I'm not thrilled about patching one driver to create
> another. That's what the original USNO driver did and that created
> problems. None of the driver sources now require any other sources
> than header files and the common interface. So, if you believe
> your driver with the Bancomm driver is not practical, please consider
> implement yours as a standalone driver.
Hello Dr. Mills,
If any of my postings led you to believe that I thought that my code
would be better off in a standalone driver, then I was unclear.
Symmetricom's version of the 635/637, which is what I want to add
support for, is only slightly different from the Bancomm 635. I thought
it would be more obviously supported by patching an existing driver,
rather than creating a new standalone driver.
If patching a driver in this fashion causes you distress, then I will
be happy to try to implement this support in whatever manner you
I interpreted your question about the TT560 as a request to consider
combining it with #16. Apparently I erred. Sorry.
None of the updates I submitted require source or headers outside of
what currently exists in the distribution. The closed-source vendor
device driver for the new 635/637 on Linux & Windows is accessed via
named function calls, instead of ioctl, so I was forced to use that
interface. I believe that it does not encumber the code, from a F/OSS
viewpoint, but am certainly not expert in such matters. If making use
of such interfaces disturbs you I will remove it.
I want you to be satisfied with the modifications I propose, and am
willing to rework any of my updates to suit you. Please advise.
More information about the questions