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

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

Reply via email to