[BusyBox] Applet Hashing for Busybox

Gaute B Strokkenes gs234 at cam.ac.uk
Wed Oct 25 17:09:31 UTC 2000


Tomi Ollila <Tomi.Ollila at sonera.com> writes:

>  Oct 25 11:39:57 +0100 2000 Gaute B Strokkenes <gs234 at cam.ac.uk> wrote:
> > Tomi Ollila <Tomi.Ollila at sonera.com> writes:
> 
> > > But it may happen that people are adding new applet in wrong place
> > > but still binary search finds it. In this case people may end up
> > > committing change without noticing that some other applet may not be
> > > found.  I am in favour of generating the applet table during
> > > compilation process.
> > 
> > The applet table is just an array that contains the applet name, a
> > pointer to applet_main, the usage message and something that tells the
> > installer where to put the symbolic link.  It's not so complicated as
> > to warrant automatic generation, IMHO.  It's much easier just to have
> > all debug builds check the order.
> 
> But, if one just adds a simple code without doing any debug builds... ?

Changing a program and then not doing a debug build before deploying
is inherently dumb and will get you into trouble no matter what you
do.

> > > BTW, which tools are suitable for doing such a work, SH and c
> > > programs certainly,
> > 
> > Using C would make bb very hard to cross-compile.
> 
> True!.. and this comes back to previous thing... if one
> cross-compiles, forcing to do debug build for simple things may not
> be what sometimes is desirable

See above; if you want to cross-compile then you should make sure that
you're compiling something that is know to be reasonably bug free.  No
one in their right mind will make a largish, arbitrary change (such as
adding an applet) and then just cross-compile blindly.

-- 
Gaute Strokkenes                        http://www.srcf.ucam.org/~gs234/
A wide-eyed, innocent UNICORN, poised delicately in a MEADOW filled with
 LILACS, LOLLIPOPS & small CHILDREN at the HUSH of twilight??





More information about the busybox mailing list