Ntpd config file support

Laszlo Papp lpapp at kde.org
Tue Mar 18 17:59:43 UTC 2014


Yes, I agree with Mike that we do not need complex signal handling for
starter. My question was more about a "start" config file parsing. I
still stick by that it would be simple and useful to add (open, read,
get value, close), but that being said, I am fine with a contribution
directory entry, too, as a compromise to avoid the arguing and get
this done. :)

On Tue, Mar 18, 2014 at 5:52 PM, Mike Dean <mdean at emacinc.com> wrote:
> I just implemented such code for a project I'm working on, and I viewed it
> as pretty trivial.
>
> In any case, Busybox is king of going half way with features, so why not
> make it just parse the config on startup and not worry about trapping
> signals?  If you do wish to implement signal handling, then a well written
> signal handler should make this easy; again, this boils down to the existing
> design, since I'm sure Busybox already handles signals.  If the struct
> you're passing a pointer to for your signal handler function includes a list
> of function pointers to handle the event, then it should be trivial to add;
> if not, then why bother?  The busybox version of vi doesn't implement many
> features, so why should the ntpd config file parsing be fully featured?
>
>
> Mike Dean
>
> mdean at emacinc.com
> http://www.emacinc.com/
>
> Engineer
> EMAC, Inc.
> 618-529-4525 Ext. 330
> 618-457-0110 Fax
> 2390 EMAC Way
> Carbondale, Il 62901
>
>
>
> On Tue, Mar 18, 2014 at 12:29 PM, Harald Becker <ralda at gmx.de> wrote:
>>
>> Hi Mike !
>>
>> > If there's code bloat from parsing a simple config file, then
>> > perhaps Busybox isn't well designed.
>>
>> Same misunderstanding as Laszlo. It is not only parsing a simple
>> config file. AFAIK libbb has functions to do this. The problem
>> is, it makes no sense to blow up the BB binary size for only
>> reading the peers address on daemon startup, without implementing
>> that right and rereading/reconfiguring the running daemon when
>> the configuration changes. And the code to handle this is more
>> than trivial.
>>
>> In my eyes bloat to the binary - as other (simpler) changes to BB
>> has bean neglected with the code size argument in the past. None
>> of the mentioned changes improves operation of the current ntpd
>> applet. Every parameter of ntpd can be given at the command line,
>> reading the info from any (config) file is simple within scripts
>> and does not increase BB binary size. So there would be extra BB
>> code for no extra functionality, because there are a some people
>> who don't get there calling scripts right (asking for extra binary
>> code, for things simple to handle in scripting).
>>
>> Why don't you provide a script with common solution, we can add
>> this to the contribution directory, for those who like to use it.
>>
>> --
>> Harald
>
>


More information about the busybox mailing list