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 <md...@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 > > 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