From owner-freebsd-hackers Fri Jan 9 14:31:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA19930 for hackers-outgoing; Fri, 9 Jan 1998 14:31:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from etinc.com ([207.252.1.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA19916 for ; Fri, 9 Jan 1998 14:31:16 -0800 (PST) (envelope-from dennis@etinc.com) Received: from dbsys.etinc.com ([207.252.1.18]) by etinc.com (8.8.7/8.6.9) with SMTP id RAA12885; Fri, 9 Jan 1998 17:32:49 -0500 (EST) Message-Id: <3.0.32.19980109173418.00e5be40@etinc.com> X-Sender: dennis@etinc.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 09 Jan 1998 17:34:23 -0500 To: Tom From: dennis Subject: Re: FreeBSD Netcards Cc: Jamie Bowden , hackers@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk 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