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.
[3g[25;9HH[25;17HH[25;25HH[25;33HH[25;41HH[25;49HH[25;57HH[25;65HH[25;73HH
<)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/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:21 EST