[BusyBox] insmod with uClibc mystery bugs

[Tom Cameron]

Matt and the Gang,
	I would have to agree with Larry on this one.  I personally use
BusyBox in applications where it is not always, or even AT ALL,
accessible with a disk media, which means I have to update the system
remotely.  This causes a problem if the kernel develops a bug, possibly
in an obscure module buried in the back of someone's config.  I need to
be able to count on BB 1000%, and so far I like the approach the
developers have taken.  I also like the approach that Larry is taking on
this one.  I personally have written Client/Server applications using an
API between the two, and have programmed in failsafes _just_in_case_ for
some _freak_ reason one doesn't talk properly to the other.  Writing
failsafes into a program is what makes stability, and stability is
important in embedded systems where you can't always CTRL+ALT+DEL, and
boot off of an install/rescue floppy.  Thanks all!

--
Thomas Cameron
Network Technician / Operations Specialist
St. Mary's Bank

> -----Original Message-----
> From:	Matt Kraai [SMTP:kraai at alumni.carnegiemellon.edu]
> Sent:	Wednesday, April 25, 2001 1:35 PM
> To:	busybox at busybox.net
> Subject:	Re: [BusyBox] insmod with uClibc mystery bugs
> 
> On Wed, Apr 25, 2001 at 09:52:26AM -0700, Larry Doolittle wrote:
> > Matt asked
> > > Why are we working around a theoretical kernel bug?
> > 
> > Because even potential infinite loops make me squirm,
> > and the cost is so small.
> > 
> > Don't think of it as a theoretical kernel bug, think of it as
> > a possible API bug.  It's good software practice to behave
> > robustly, even when the other side of an API doesn't do what
> > you expect.
> 
> If I understand correctly, you are saying that we should modify
> BusyBox so that, if the kernel ever contains an off-by-one error,
> we will not enter an infinite loop.  This is bogus.  If the
> kernel contains an off-by-one error, it should be fixed, not
> BusyBox.
> 
> If there are other reasons (it is clearer, it is smaller, it is
> quicker, etc.) then by all means commit it.  But please don't do
> it to compensate for a (non-existent) bug somewhere else.  If we
> enter an infinite loop, it is the kernel's fault for not living up
> to its API, not ours for adhering to it.
> 
> Matt
> 
> 
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://busybox.net/mailman/listinfo/busybox