Ntpd config file support

[Harald Becker]

Hi Denys !

>I don't know... I still feel compat is important.
>It means growth of user base.

Compatibility with what? Busybox ntpd is not exactly modeled as
upstream ntpd ... and it's the reason why I use BB ntpd, as I
like it's simplicity, and dislike the upstreams complexity for a
minimalistic operation.

>Most of features are "bloat". CONFIG_FEATURE_FIND_DELETE
>is bloat - you can easily code it with -exec instead, right?

Wow this is a completely unfair compare.

You compare a feature which is heavily used by many users in
many scripts and many command line usages, with a feature for a
few admins not willing to read some config in scripts and create
there command line correct.

Think of this twice, before throwing in such kind of bloat. BB
ntpd has all features required to do it's job. Every parameter
can be set on command line. The request to have a config file is
only from those not willing to read such config from compatible
config file and place it in command line during daemon startup.

Examples of how this compatibility can be achieved without adding
the bloat has bean given in the thread. So if you add this kind
of config it is not like other heavily used features (e.g. find
-delete). It will add bloat for a few people not willing or able
to get a single start script right and add a hand full of lines
to read values from compatible config file on daemon startup.

As this I consider it highly optional *AND* *NOT* part of a
default build.

Don't misunderstand. I don't want to block the feature, if you
like to add it, but optional and only included if system
creature explicitly selects it, and not part of a default build.

>- support for paranoid levels of compat (grep of NUL byte)

IMO a paranoid level of compatibility, for those not willing to
write a hand full of lines in a daemon startup script (a single
script on a system). This is what I call this ntpd config file
feature. So let it default to NO.

--
Harald