Date: Fri, 9 Jan 1998 10:10:40 -0800 (PST) From: Tom <tom@sdf.com> To: dennis <dennis@etinc.com> Cc: Jamie Bowden <jamie@itribe.net>, hackers@FreeBSD.ORG Subject: Re: FreeBSD Netcards Message-ID: <Pine.BSF.3.95q.980109100102.1512B-100000@misery.sdf.com> In-Reply-To: <3.0.32.19980109111929.00e5a310@etinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 9 Jan 1998, dennis wrote: > >> Well, the benchmarks are not about performance as we really think of it - > >> as in faster is better. These benchmarks are about how well the system > >> stands up to rocks beting thrown at it. Meaning, does the system casue ... > >> So, as far as that goes, freeBSD was, to my surprise, one of the worst > >> offenders. Linux, on the other hand, did very well in our tests. I have > >> given it alot of thought, and I think I know why this is. I think that > >> the average freeBSD user is in general a more advanced computer person, > >> who knows how to operate a system, and programs well (excluding you of > >> course on the last item :) ). Thus when her/his program aborts > >> catastrophically, they debug it, and feel stupid that they did something > >> like pass NULL to atoi (which actually causes an abort in freeBSD). The > >> linux users, on the other hand, can't figure it out, or bitch and whine, > >> and as a result, the system call is fixed to return an error code instead > >> of an abort. Since you have to know about these bugs to fix them, it > >> seems likely that freeBSD users/programmers just do fewer stupid things. atoi isn't a system call. A program that passes a NULL to atoi isn't going to work. The fact that you get an ABORT vs. an error message is just a matter of assisting debugging. Neither result is more correct than the other. > a couple of years ago I suggested a serious look at all this stuff, but making > 'BSD unix crash proof doesn' t seem to be a major criteria. Any system that > panics when an invalid raw socket command is issued is in serious need of > work. This is bit of tangent. Making library calls produce error messages when passed non-sensical data has nothing to do "crash proofing". Such programs will die anyhow, but aren't going to take the system down. This is raw socket stuff is interesting. Example source please. I don't believe this problem exists anymore. I know that Julian fixed problems with routing sockets. As a side point, routing sockets and raw sockets can only be accessed by root processes. At this point, you will argue that not even root should be able to crash the machine. Perhaps you are right. But there are many ways on FreeBSD and Linux for root to crash the system. Both Linux and FreeBSD root processes can access raw i/o ports. > There are MANY instances where panics are used inappropriately...where > an error return or warning would keep a system from crashing. Another tangent. Panics have little to do with application errors that were described in the original message. In fact there was no mention of panics at all. The only panic I've ever seen is "page fault in kernel mode", which is pretty unrecoverable. What are these panics that are so easily recoverable? > Dennis Tom
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.980109100102.1512B-100000>