This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Thu Jun 13 14:38:37 2024 Received: from spaans.ds9a.nl (adsl-xs4all.ds9a.nl [213.84.159.51]) by kylie.puddingonline.com (8.11.6/8.11.6) with SMTP id g8HKici11437 for ; Tue, 17 Sep 2002 22:44:39 +0200 Received: (qmail 1371 invoked from network); 17 Sep 2002 20:25:40 -0000 Received: from unknown (HELO spaans.ds9a.nl) (3ffe:8280:10:360:202:44ff:fe2a:a1dd) by mayo.ipv6.ds9a.nl with SMTP; 17 Sep 2002 20:25:40 -0000 Received: (qmail 25423 invoked by uid 1000); 17 Sep 2002 19:46:52 -0000 Received: (maildatabase); juh Received: (qmail 4383 invoked by alias); 23 Oct 2000 20:41:48 -0000 Received: (qmail 4039 invoked from network); 23 Oct 2000 20:37:53 -0000 Received: from vger.kernel.org (199.183.24.194) by spaans.ds9a.nl with SMTP; 23 Oct 2000 20:37:53 -0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 23 Oct 2000 16:52:50 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 23 Oct 2000 16:52:40 -0400 Received: from chaos.analogic.com ([204.178.40.224]:6660 "EHLO chaos.analogic.com") by vger.kernel.org with ESMTP id ; Mon, 23 Oct 2000 16:52:28 -0400 Received: (from root@localhost) by chaos.analogic.com (8.11.0.Beta3(chaos.analogic.com)/8.11.0.Beta3) id e9NKZSW01648; Mon, 23 Oct 2000 16:35:28 -0400 Date: Mon, 23 Oct 2000 16:35:28 -0400 (EDT) From: "Richard B. Johnson" Reply-To: root@chaos.analogic.com To: Dennis Cc: "Dwayne C . Litzenberger" , linux-kernel@vger.kernel.org Subject: Re: Topic for discussion: OS Design In-Reply-To: <5.0.0.25.0.20001023143722.022a2b60@mail.etinc.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 23 Oct 2000, Dennis wrote: > This is typical of the "linux mentality". Why do other OSs have solutions > that work, yet linux's method requires special coding? If it "has to be > done that way", why do other OS's have solutions that dont do it that way? > the size of the buffer is an annoyance but not a serious problem however. > I'm not sure that Linux requires any special coding. > printing directly to the console (as BSD does) is useful when debugging a > panic, as you can trace right to the panic point. Also certain levels of BSD does not write directly to the console. Its console is a direct clone of Linux. I'm not sure which came first, but when you have a single screen-card there are not too many ways to get the character and attribute into screen memory. Linux allows the console to be redirected to a serial port. BSD does not last time I checked. > > > >Bugs that were found when changing the design of various kernel > >procedures, have been back-ported to the stable kernel series. > > I never use development kernels, what Im talking about is each major > release is like starting from version 1.0. By the time it stabilizes, the > next major puts it back to square one. What? The API has remained consistent since 0.99. It's only internal kernel stuff that has changed. If you wrote code that worked on 0.99, it will still compile and work on 2.2.17. You could not have written code for 0.99 that used mmap() and some other stuff because it had not been developed yet. However, all the "Unix stuff" like read/write/open/close/ioctl/lseek, etc., and their buffered versions like fopen() from the 'C' runtime library, have had the same API since day one. Linux was developed, from the start, to have a POSIX compatible API. Most of that API comes from the 'C' runtime library, the exact same API used by BSD and all the other OS's to which the GNU library has been ported. The only reason to get the 'latest' version is to take advantage of increased functionality. This, by definition, means that something has changed. That's what you upgrade for. The word "unstable" is a misnomer. > My point is that there is no "stable kernel series". 2.2.0 wasnt stable, > and neither was 2.2.3. Virtually all of the ethernet drivers still lock up > under heavy load in 2.2.17...and now with 2.4 there are more countless > adventures ahead.... Which Ethernet drivers are you having trouble with? The ones that had lockup problems (incidentally hardware related), now have reset code that runs off a watch-dog. > an example of "poor planning" is that skput and skpush will panic the > kernel if there is no room (this can happen with multiple encapsulations) > The proper behaviour would be to return a NULL pointer indicating failure, > and then to drop the frame and issue a warning. The proper response to any resource not being available (in networking) is to drop the packet on the floor, smash it into little pieces, and don't tell anybody about it. The packet will be sent again. But, if you can't transmit a packet, therefore freeing a buffer, what do you do? What you do is realilize that the failure to transmit was likely caused by a disconnected wire. In the drivers I use, I simply pretend that every packet got transmitted okay. This usually involves a one or two-line modification to the driver. This has nothing to do with poor planning. It just has to do with a design decision that I didn't agree with. Somebody decided that network data was precious and therefore the machine should kill itself if necessary to get the data through. I didn't agree with this so I changed a few lines of code. You can't kill any of my machines by flooding them and they never lock up. Further, they run at 85 to 90 percent of the network physical layer bandwidth. My main machine is our domain name-server, it gets between 2000 and 5000 hits per second. If it crashed, our whole LAN goes down. It doesn't. It runs Linux-2.2.17. Script started on Mon Oct 23 16:12:02 2000 # rlogin boneserver Password: Last login: Mon Oct 23 11:28:29 from chaos.analogic.com Linux 2.2.17. HHHHHHHHH <)0 # uptime 4:12pm up 24 days, 22:21, 11 users, load average: 0.81, 0.62, 0.00 # exit logout rlogin: connection closed. # exit exit Script done on Mon Oct 23 16:12:27 2000 Those 11 users are all network servers including samba for M$ connectivity. One of the major advantages of Linux is that if you don't like a design decision that was made, you are free to do it over the way you think is right. Sometimes you can convince others that your way is better. Sometimes not. If so, your patch makes it into the main-line kernel, if not, you patch your own future kernels so you get to retain your improvements. FYI, if AC did not exist, another would appear to fill the vacuum. Don't bitch. Make some improvements and send patches. Cheers, Dick Johnson Penguin : Linux version 2.2.17 on an i686 machine (801.18 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/