[Subject says NetBSD, but context has drifted to MacOS] > That said, I'm going to push - not hard, not hill-to-die-on, just moderately > - for remaining strict about our C99 conformance policy and culling old > releases/minor platforms that can't meet it.
We aren't discussing C99 but rather the non-standardize way of playing with the clock. I know of two ways to handle that sort of problem. One is to use ifdefs like the current code. Being hard-nosed about C99 helps keep that sort of code clean. The other way is to have a separate module for each OS and link in the right one. That only works if you have a clean API for what the module has to do. The downside is that you usually have a lot of duplicated code, and if you make a change/fix in one place, you have to go check the other places, and remember to do it. This might be an appropriate time/place to use the separate module approach. The API is simple and clean. Ignoring MacOS, I think the current code has 2 branches. One is with ntp_adjtime or similar. The other is without it. I think that 's currently ifdef-ed with HAVE_KERNEL_PLL. If ifdef-ing the no-ntp_adjtime module to support MacOS gets too ugly, we could use a separate module. By the way, "HAVE_KERNEL_PLL" is a horrible name. There is no PLL involved. There are two features we want. One is to be able to slew the clock. The other is to tweak the clock frequency, aka drift. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
