lkml.org 
[lkml]   [2000]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Topic for discussion: OS Design
At 04:35 PM 10/23/2000, you wrote:
>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.


- FreeBSD will display kernel print messages with syslogd not running, and
linux will not.
- FreeBSD doesnt (seem) to have the buffering problem that linux does, in
that exceptionally long messages (like decoding a Frame Relay LMI frame
with 1000 elements) work just fine.
- FreeBSD will display messages immediately without a newline
- FreeBSD messages 1) can be redirected and 2) are printed without a timestamp.

which implies that you are wrong about just about everything.

>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.

We are talking about the kernel. What are you talking about? The external
view is meaningless.

the device driver interface changed substantially in 2.0. The module
interface changed, as it is changing again in 2.4. The PCI interface has
changed and is changing again.


>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.


Usually my customers want to upgrade because of some security fix or bug
fix, not to get new features.


> > 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.


The eepro100 driver is an ongoing project, still with lockup problems. the
tulip has issues as well.



> > 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.

Right. So your answer is that linux is OK if you modify all of the broken
stuff yourself. Im glad we are in agreement on that, if nothing else.
DB

-
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/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.112 / U:5.552 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site