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 _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
