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