Ntpd config file support

[Laszlo Papp]

Harald,

you would not use the minimal config, so your workflow would not
change anyway, and it is not like the complex use case you suggested
with all the signals and all that. It is a reasonable compromise in my
opinion. Parsing those two variables from a file is trivial, and would
increase the code size probably only with a few KB?

As for the -exec, I currently do not understand why it would be as
common as you seem to indicate it. Perhaps, you can show the "many
uses" as you imply?

I see a config file issue resolved bigger gain than avoiding "-exec".
Thereby, I personally think Denys' comparison was fair.

On Thu, Mar 20, 2014 at 3:11 PM, Harald Becker <ralda at gmx.de> wrote:
> 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