I think that adding this feature is an excellent idea. I don't understand where all the resistance is. If there's code bloat from parsing a simple config file, then perhaps Busybox isn't well designed. I don't know, I haven't worked with it's code; perhaps I'm just used to the Linux kernel's code, but considering the number of utilities (including daemons) that Busybox replaces, why doesn't it have generic library code for parsing configuration files? If you want to cast stones regarding bloating code with configuration parsing, you should at least cast them in the right direction. If each individual tool that Busybox replaces has its own code for parsing a configuration file (if it uses one), then *that* is the problem, not the desire of users to have this feature. I really don't understand this resistance to meeting the needs of the end users. Personally, I think this type of resistance will only lead to people eventually forking Busybox due to disagreements with the decisions made regarding these types of features. #ifdefs work very well for selectively leaving out features like this, as I imagine you know, without leaving behind and code bloat in binaries which have the feature disabled. One of the previous respondents to this chain suggested making it a menuconfig option; that sounds very reasonable to me.
Looking back through this e-mail chain, it appears to be a 4:1 ratio so far of people for this feature to people against. If 4 people want it, and only 1 person doesn't, doesn't that sound like a feature that *should* be implemented? It sure does to me. Mike Dean [email protected] 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 9:49 AM, Laszlo Papp <[email protected]> wrote: > That is the fourth solution I see now in a raw... after Yocto, > Buildroot and OpenWrt... > > This is what I was referring to. It is inconsistent across projects. :) > > That being said, it seems that Harald is objecting to this heavily for > some reason (may be miscommunication between us). Thereby, I will not > insist on this. If the developers feel happier without that feature, > let it be so. > > On Tue, Mar 18, 2014 at 2:32 PM, Cristian Ionescu-Idbohrn > <[email protected]> wrote: > > On Tue, 18 Mar 2014, Bryan Evenson wrote: > >> > >> How about a set of ntpd menuconfig options to build the command > >> line? We could configure the default ntpd settings at build time, > >> it wouldn't add anything to the size of the final ntpd binary. > > > > How about using a resource file the initscript would source: > > > > ---[ rc-file ]--- > > NTPD_OPT1='-f foo' > > NTPD_OPT2='-b bar' > > NTPD_OPT3= > > ----------------- > > > > ---[ initscript ]--- > > #!/bin/sh > > > > . /path/to/rc-file > > ... > > <command line to start> ntpd $NTPD_OPT1 $NTPD_OPT2 $NTPD_OPT3 > > ... > > -------------------- > > > > > > Cheers, > > > > -- > > Cristian > > _______________________________________________ > > busybox mailing list > > [email protected] > > http://lists.busybox.net/mailman/listinfo/busybox > _______________________________________________ > busybox mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/busybox >
_______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
