Harald, I would but I'm busy porting existing device drivers to Device Tree and writing some new drivers. Our last release used a kernel version that didn't have Device Tree, so getting support for all the hardware on all of our boards for this new kernel version is a substantial amount of work.
I will give you a use case where this feature makes sense, though: we build embedded Linux images using Yocto, but unlike many people, we make our images generic and add additional tools and a fully featured SDK. We build our distribution for customers who don't know how to do this themselves, and don't have the inclination or approval to spend the time learning how to. We work hard to make things easy for them. One of the stumbling blocks our customers have had in the past is how to configure ntpd to use their internal ntp servers. Helping them with this usually results in grumbling about it being overcomplicated to perform what should be such a simple task. Most of them have no idea how to write bash scripts, so this task represents a real learning curve for them. What makes this worse is that they have no interest in learning bash; as soon as they finish this, they go back to C++ (or C) to finish their work. Now, personally, I've been writing software since the mid-1980's, so to me, all software is much easier to write than it used to be, and the library functions keep the code size small. I personally don't see how this tiny addition represents any significant increase to the size of the source tree or the compiled binary. I will tell you, however, that we'll just continue use the full version of ntp for our upcoming distribution (we already made the switch in our recipes) if this isn't added. It's not worth the time or effort for me to edit your code to add this. I've simply been trying to point out that catering to your users is the most important thing to do if you want to keep them from jumping ship. This may be one small portion of Busybox, but it's one of about 20 that we've already replaced with full versions for our upcoming release; the shortcomings in the busybox versions aren't worth the savings in size in the days of GHz processors and 512MB+ RAM on small cheap embedded systems. They're not even worth the savings on our lowest end 200 MHz models; even those have a minimum of 128MB of RAM. I hope I'm not coming off as stubborn, annoying, or similar; that's not my intention. I'm just trying to get you to see things from the standpoints of the people in this chain who've all clamored in favor of the feature. It honestly doesn't bother me either way, because as I said, I'll just use the full version instead and not worry about it. 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 1:35 PM, Harald Becker <ra...@gmx.de> wrote: > Hi Mike ! > > On 18-03-2014 12:52 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. > > So why don't you provide an example for a patch to implement the > function you request ... with full bloat check output and > description of benefits ... then we can see if it makes sense to > implement this. > > -- > Harald >
_______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
