Date: Sun, 16 Aug 2015 22:49:57 -0700 From: Cy Schubert <Cy.Schubert@komquats.com> To: Ian Lepore <ian@freebsd.org> Cc: Matthew Seaman <matthew@FreeBSD.org>, freebsd-stable@freebsd.org, Cy Schubert <cy@FreeBSD.org>, roberto@freebd.org, phk@freebsd.org, delphij@freebsd.org Subject: Re: 10.2: ntp update breaks DCF77 clock Message-ID: <201508170549.t7H5nvxD009140@slippy.cwsent.com> In-Reply-To: Message from Ian Lepore <ian@freebsd.org> of "Sun, 16 Aug 2015 10:57:00 -0600." <1439744220.242.87.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <1439744220.242.87.camel@freebsd.org>, Ian Lepore writes: > > > --=-yOSDvPzQIQnw2oRARoLp > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: 7bit > > On Sun, 2015-08-16 at 08:10 +0100, Matthew Seaman wrote: > > On 15/08/2015 16:46, Christian Weisgerber wrote: > > > The ntp code is not very transparent, but I think the root cause > > > are the ntp/config.h changes that came with the 4.2.8p3 update. A > > > number of previously disabled obscure clock drivers were enabled, > > > but crucially CLOCK_RAWDCF was disabled, and this is the PARSE > > > subdriver needed to use the popular DCF77 serial receivers. > > > > > > Frankly, it looks like we used to have a carefully considered > > > selection of clock drivers which has been blindly splattered with > > > the upstream defaults in the last update. > > > > Hmmm.... I suggest raising a PR with patches to revert the changes in > > the set of enabled clock drivers (or merge with the current list). It's > > not going to get you a working DCF77 receiver in a -RELEASE version any > > time soon, I'm afraid, as you'll have to wait until the next release for > > the changes to percolate down, but having a sensible list of enabled > > clock drivers in base is definitely a good move. > > > > I wonder: is there a reason to not enable all (or most of) the refclocks > in base and in ports? Well, at least all the ones that build on > freebsd... a disturbing number of them fail to compile because they > include linux-specific header files. Hmm, I just noticed that we > actually compile most of the refclocks, but we don't enable them in the > config. The reason not to include all drivers is fourfold. 1. Support of all drivers does increase the risk out-of-the-box breakage and security exposure. Not often used drivers may contain additional security exposures. 2. IMO, a client-only configuration should be supported. I've been told via email (which I was cc'd) exchanged between a person on the project and our NTP upline (at ntp.org) that a timekeeping client able of understanding multiple protocols (e.g. PTP) is in the works and will someday (soon?) replace ntp in base. Avoiding too much function creep may avoid POLA when that occurs. 3. Some drivers may interfere with each other. This is why ntp as distributed by our upline does not turn them all on, and which is why the port allows a user to install them as required. I've heard of occasional conflicts over the years. Turning them all on could be a risk for the project, as in someone may have to needlessly fix something that has not been tested or supported by our upline. With the port OTOH, it's easy to tell a user to turn off whatever they don't need. 4. Also IMO, that's what the port is for. If a person wants to use ntp as a server, e.g. to serve time to other computers, i.e. not simply use ntp as a consumer, then the port is always available. (Also juxtapositioned to this point, the port is updated before base because testing and commit [commit to vendor branch, MFV, build tinderbox, run for a while, MFC] is much simpler with the port than in base.) As to why, historically, not all drivers have been built and installed is something I cannot answer, though I hazard to guess it may be due to one or more of the above. IMO I'd prefer to keep ntp minimal within base and direct people who want more to one of the ports. (The ports collection has a -rc incarnation when release candidates are available.) > > It looks like the cost of enabling all the refclocks that compile > properly is pretty small... doing so increased the size of ntpd from > 745K to 801K for me. I'll attach the diff just to save someone else the > trouble of iteratively figuring out which ones won't build, but I think > there may be a more-proper way to generate this config by tweaking the > autotools stuff. Size of the binary is not an issue. I'll be working on generating config.h. The issue here is that config.h is different for each supported FreeBSD platform (32bit, 64bit, little and big endian, etc.). The plan is to make config the port on each supported platform using qemu-sbruno and steal ^W borrow the config.h and import into base, using a master config.h (actually called config.h) to include via #ifdef definitions the appropriate config.h.<PLATFORM_NAME>. Qemu (and qemu-sbruno) doesn't support all our supported platforms, especially the multitude of ARM platforms, so holes in our auto-generated config.h support will exist. Thanks for the diff. I think the place to start is to enable them in a (new) dependent port (ntp-all and ntp-devel-all for the lack of better names) and see what fallout comes from it. -- Cheers, Cy Schubert <Cy.Schubert@komquats.com> or <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201508170549.t7H5nvxD009140>