Date: Fri, 09 Jan 1998 17:34:23 -0500 From: dennis <dennis@etinc.com> To: Tom <tom@sdf.com> Cc: Jamie Bowden <jamie@itribe.net>, hackers@FreeBSD.ORG Subject: Re: FreeBSD Netcards Message-ID: <3.0.32.19980109173418.00e5be40@etinc.com>
next in thread | raw e-mail | index | archive | help
At 10:10 AM 1/9/98 -0800, Tom wrote: > >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. Just look in raw_usrreq(). the default case is a panic. > > 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. You were talking about inappropriate handling of exception conditions, which seems to be a parallel. db
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.32.19980109173418.00e5be40>