[BusyBox] insmod on old kernels

[Vladimir N. Oleynik]

Mark Whitley wrote:

> > Wow! Good virus :)))))))
> > Ohhh,
> > Don`t use bsearch in find applet, its have big code and slow
> > and previous realisation error.
> > Points: ftp://ftp.simtreas.ru/pub/my/bb/new/bsearch_tst.c.gz
> > (Maintainers ignore this points :( )
> 
> Some responses:
> 
> #1) You appear to be blaming bsearch for the problem Julien Gaulmin is having.
> He is, in fact, getting the problem from strcmp, not bsearch.

Maybe. I not have this architecture.
Example is not strcmp, but bsearch.
 
> #2) bsearch is not big and slow, as you constantly complain. Here is an entire
> listing of the bsearch function of uClibc:
> 
>         char *bsearch(key, base, num, size, cmp)

I have now uclibc.
I have sources glibc.
I have Donald Knuth books. (Ohh, russian translate, right?)

> It is ~15 lines of code (not big) and runs in O log(n) time (not slow).
> 
> #3) I have tested your program bsearch_tst.c on my box and got the following
> results:
> 
> Clear    test 10000000 iterations, 80098 misses, time   4.0740s
> Bsearch  test 10000000 iterations, 80098 misses, time  20.4670s
> Linear   test 10000000 iterations, 80098 misses, time  25.1740s
> Bsearch2 test 10000000 iterations, 80098 misses, time   6.8810s

Hmm. My box: Intel PII333. Compiling with -Os.
 
> You will note that the FASTEST times were obtained when using bsearch -- not
> by using the linear search -- despite all your claims of bsearch being slow. I
> am surprised that you missed this in your own testing.

Ok. Diffirent 5e-4 s. This principial for addition ~15 lines code? 
This code not user in many FULL Linux distribution applets.

> Your fastest time (other than 'Clear' of course) came from using Bsearch2,
> that is bsearch with a new applet_name_compare() function that used this as
> the 'return' line:

I put bsearch2 test special for demonstrate "erroneous problem".
I not require put this code to busybox.
 
> #4) You make the assertion "Maintainers ignore this points". We are human and
> things slip by us sometimes. (See the thread last month re: "Improving Our
> Development Process" for some ideas we came up with that address "lost
> patches", among other things.) You will find that, useful code, when presented
> in a polite, non-confrontational manner, will indeed catch our attention, and
> we will be happy to include it in future versions of busybox.
> 
> On the other hand, code that is badly written, poorly tested, and backed by
> claimes of virusus (?) and similar noise, will likely be ignored.
> 
> I hope these guidelines will help you in the future when you have a patch that
> you want to be included in busybox.

Ohh. Very long english text.
I require answer - please wait weekend. Exuse me.


--w
vodz