Ntpd config file support

[Laurent Bercot]

On 18/03/2014 20:12, Mike Dean wrote:
> So it's difficult to provide and document a configuration file like this?

  It's not difficult.
  But it conflicts with some of the goals of Busybox.

  Parsing a config file has several drawbacks:
  - It is much more complicated than reading command-line arguments. It
requires *a lot* more code, and parsing code is error-prone. In the
grand scheme of things, a simple parser might not seem much, but when
a tool tries to be as small and simple as can be, adding an unneeded
parser is not the way to go.
  - It adds state in the filesystem. When you run the "ntpd" command line,
what happens now depends on your config file. Also, it adds a burden on
the programmer: what if the state changes? And now he wants to add
signal handling to the small tool to gracefully handle config change
notifications via SIGHUP. Your program is now using a parser and the
signal stack, for no obvious benefit. Again, this might not seem much,
but changing from stateless to stateful should not be done lightly,
especially for a Busybox applet.

  You are the distributor. If you feel your users will be more at ease
with a configuration file, by all means, write a program that parses
a configuration file into command-line arguments and launches ntpd with
those arguments. It's not difficult, you said so yourself; and everyone
will be happy. But that's your job as a distributor, it's not upstream's.


> I can see that we'll be using the full version of ntpd on our distro.
>  You've fully convinced me that it's the most wise choice to make.

  ... oh. Well, if you feel that switching to full ntpd will be less work
for you than writing a trivial config parser, and you can live with
eating 20 times as much resources, it is indeed the wise choice to make.

-- 
  Laurent