lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
eec934fe6cdf00ff46c70c324c1949d18222ecc3
oldlinux-files/docs/mail-archive/linux-activists/Linus in Linux-group.txt
gohigh 9912ec445d add directory docs
2024-02-19 00:23:35 -05:00

12586 lines
511 KiB
Plaintext
Raw Blame History

Linus Torvalds Posts on comp.os.linux
Searched Groups for group:comp.os.linux author:Linus author:Torvalds.
Results 401 - 434 of 434.
===============================================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: HD timeout Errors (with .95a)
Keywords: IDE
Message-ID: <1992Apr3.144129.15122@klaava.Helsinki.FI>
Date: 3 Apr 92 14:41:29 GMT
References: <1992Apr3.030517.29450@afterlife.ncsc.mil>
Organization: University of Helsinki
Lines: 25
In article <1992Apr3.030517.29450@afterlife.ncsc.mil> sdbaker@afterlife.ncsc.mil (Stewart Baker) writes:
>Is there anyone else having problems with their disk in .95a?
> [ description deleted ]
I'm afraid there are people still having problems with the 0.95a
harddisk drivers: the problems show up in "unexpected HD interrupt" and
"HD timeout" messages. These messages sometimes result in read-errors,
it seems: general protection errors and sometimes even bad filesystems.
I'll make a new alpha-patch available tomorrow, which has some
corrections to the harddisk driver: they aren't guaranteed to help you,
but I hope the few persons experiencing these errors will try them out
and report to me what happened.
The upcoming alpha-patches will also contain other corrections: the
387-emulation had bugs (corrections were already sent to the gcc-2
beta-testers) and there has been some further work done on the VFS-code
(thanks to entropy and card) as well as some other corrections (hedrick,
bruce evans etc pointed out bugs..)
I'm afraid the patches will be against a clean 0.95a once more: people
with other patches might have problems. The ps-patches are incorporated,
btw.
Linus
=================================
=================================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Help, can't compile 0.95a!
Message-ID: <1992Apr3.212741.3018@klaava.Helsinki.FI>
Date: 3 Apr 92 21:27:41 GMT
References: <1192@lysator.liu.se> <magister.702263905@garfield.catt.ncsu.edu> <03.04.92.020516.223@cogsci.cog.jhu.edu>
Organization: University of Helsinki
Lines: 44
In article <03.04.92.020516.223@cogsci.cog.jhu.edu> wjb@cogsci.cog.jhu.edu (Bill Bogstad) writes:
>
> I have a 8 Meg system and also am having problems compiling fork.c.
>I would have thought that would have been sufficient....
Ok, the problem isn't memory: it's gcc-1.40. For some strange reason
the older gcc runs out of registers when optimizing some of the files in
the linux source distribution, and dies. This one isn't the same bug as
the "unknown insn" which was due to my hacks in the earlier 1.40 - this
one seems to be a genuine gcc bug.
Linux 0.95a is compileable with the older gcc if you just add the flag
"-fcombine-regs" to the command line. In fact, the only thing you need
to do is to remove a "#" from the makefiles: the line
#GCC_OPT = -fcombine-regs
should be uncommented, and gcc-1.40 will have no problems compiling the
source. This was documented in some of the release-notes for 0.95, but
I guess I forgot it for 0.95a.
Why remove the flag in the first place I hear you say? Simply because
gcc-2 doesn't understand -fcombine-regs, as it seems to do the
optimizations even without asking. There are other things I had to
change in the source to get gcc-2 to compile it, but this is the only
problem that made the old gcc choke.
With the advent of an official gcc-2.1 (this weekend?), people might
want to change to that one: note however that gcc-2.1 is about twice as
big as 1.40, so it's going to be slower on machines that swap... People
with just 2M of mem might not want to upgrade (*). I like the changes
to 2.1: the code quality seems to be a lot better (esp floating point).
On a slightly related note: the as-binary in newgcc has been reported by
several people to have problems. Getting as from the original
gcc-distribution by me (gccbin.tar.Z) might be a good idea if you have
problems with the newgcc version.
Linus
(*) Even with only 2M of mem, using gcc-2 has it's good points. The
shared libraries should cut down on memory use as well as loading time
and disk-space use. Shared libraries work even with 1.40 if you know how
to build them, but 2.1 does it all automatically...
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: What is linux?
Keywords: linux
Message-ID: <1992Apr3.214400.3551@klaava.Helsinki.FI>
Date: 3 Apr 92 21:44:00 GMT
References: <1992Apr1.182702.8464@colorado.edu> <1992Apr02.135130.26689@watson.ibm.com> <IMHW400.3@INDYVAX.IUPUI.EDU>
Organization: University of Helsinki
Lines: 28
In article <IMHW400.3@INDYVAX.IUPUI.EDU> IMHW400@INDYVAX.IUPUI.EDU (Mark H. Wood) writes:
>In article <1992Apr02.135130.26689@watson.ibm.com> lpickup@xanadu.btv.ibm.com (Lance Pickup) writes:
>
>>While not part of the original question, it's worth mentioning that
>>Linux requires an ISA bus--no MCA )-;
>
>Is this just because nobody's done it, or LINUX' structure would make it too
>difficult, or is it a matter of principle :-) ? Seriously, if anybody is
>working on MCA mods, I'd like to know. If not, I may take a stab at it
>myself, so my poor underemployed PS/2 can have a real operating system, in
>addition to MeSs-DOS.
It's not due to some internal linux-design: linux does count on a 386+
processor, but there isn't any heavy kernel dependancy on the AT-bus.
HOWEVER: most device driver will probably have to be changed to some
degree, but I haven't got the slightest idea of what is needed.
The minimum needed to make a PS/2 port is a very thorough knowledge of
the interrupt and IO system of the MCA systems, as well as patience and
a feel for kernel programming (debugging is /hell/ when nothing works -
no debugger I know of can follow the code from real mode to protected
mode and paging-setup etc - you'd probably need an emulator). I can
help with questions about the current code, but I have /no/ idea of what
the microchannel architecture changed with respect to the ISA standard,
so you are essentially on your own in that respect. I assume DMA, A20
etc have changed - I know the keyboard seems to work differently etc...
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Since I haven't seen an FAQ...
Message-ID: <1992Apr4.102225.13174@klaava.Helsinki.FI>
Date: 4 Apr 92 10:22:25 GMT
References: <1992Apr3.190450.28708@pony.Ingres.COM>
Organization: University of Helsinki
Lines: 138
In article <1992Apr3.190450.28708@pony.Ingres.COM> sergio@Ingres.COM (Sergio L Aponte) writes:
>
> Can somebody give me a two-three liner description of what is LINUX
> and what hardware it runs on?
Ok, this has come up so many times I'd better send out the info-sheet.
The FAQ is maintained by corsini@?? and he'll send out the newest
version just as soon as this newsgroup gets that far.
This info-sheet is basically the old 0.12 info-sheet with very minor
modifications: I've changed it slightly, but it's not completely up to
date.
Linus
----------
LINUX INFORMATION SHEET
(last updated 13 Jan 1992 (with changes by Linus 4.4.92))
1. WHAT IS LINUX 0.95a
LINUX 0.95a is a freely distributable UNIX clone. It implements a
subset of System V and POSIX functionality. LINUX has been written
from scratch, and therefore does not contain any AT&T or MINIX
code--not in the kernel, the compiler, the utilities, or the libraries.
For this reason it can be made available with complete source code by
anonymous FTP. LINUX runs only on 386/486 AT-bus machines; porting to
non-Intel architectures is likely to be difficult, as the kernel makes
extensive use of 386 memory management and task primitives.
Version 0.95a is still a beta release, but it already provides much
of the functionality of a System V.3 kernel. For example, various
users have been able to port programs such as bison/flex without having
to modify code at all. Another indication of its maturity is that
it is now possible to do LINUX kernel development using LINUX itself
and freely-available programming tools.
2. LINUX features
- System call compatible with a subset of System V and POSIX
- Full multiprogramming (multiple programs can run at once)
- Memory paging with copy-on-write
- Demand loading of executables
- Page sharing of executables
- Virtual memory: swapping to disk when out of RAM
- POSIX job control
- virtual consoles
- pty's
- some 387-emulation
- ANSI compliant C compiler (gcc)
- A complete set of compiler writing tools
(bison as yacc-replacement, flex as lex replacement)
- The GNU 'Bourne again' shell (bash) (as well as 'ash', 'rc' etc)
- Micro emacs
- most utilities you need for development
(cat, cp, kermit, ls, make, etc.)
- Over 200 library procedures (atoi, fork, malloc, read, stdio, etc.)
- Currently 6 national keyboards: Finnish/US/German/French/British/Danish
- Full source code (in C) for the OS is freely distributable
- Full source code of the tools can be gotten from many anonymous ftp sites
(Almost the entire suite of GNU programs has been ported to Linux.)
- Runs in protected mode on 386 and above
- Support for extended memory up to 16M on 386 and above
- RS-232 serial line support with terminal emulation, kermit, zmodem, etc.
- Supports the real time clock
3. HARDWARE REQUIRED
- A 386 or 486 machine with an AT-bus. (EISA will probably work, also,
but you will need an AT-bus hard disk controller.) Both DX and SX
processors will work.
- A hard disk implementing the standard AT hard disk interface -- for
example, an IDE drive. In addition, some SCSI drives are supported
with additional kernel patches.
- A high-density disk drive--either 5.25" (1.2MB) or 3.5" (1.44MB).
- At least 2 megabytes of RAM. (LINUX will boot in 2 Mb. To use gcc
4 MB is a good idea.)
- Any video card of the following: Hercules,CGA,EGA,VGA
In addition, LINUX supports
- Up to four serial lines (2 active at a time)
- A real time clock
4. PARTIAL LIST OF UTILITIES INCLUDED IN OR AVAILABLE FOR LINUX 0.95a
- The MTOOLS package (reading/writing to DOS filesystems)
- The complete GNU filetools (ls, cat, cp, mv, ...)
- The GNU C and C++ compiler with GNU assembler, linker, ar, ...
- bison
- flex
- rcs
- pmake (BSD 4.3 Reno/BSD 4.4 make)
- kermit
- Micro emacs
- less
- mkfs
- fsck
- mount/umount
- TeX, dvips
- and lots more...
5. LINUX BINARIES
The LINUX binaries and sources are available at several different
anonymous FTP sites. The biggest are:
nic.funet.fi:/pub/OS/Linux
tsx-11.mit.edu:/pub/linux
6. LEGAL STATUS OF LINUX
Although LINUX is supplied with the complete source code, it is
copyrighted software. Unlike MINIX, however, it is available for free,
provided you obey to the rules specified in the LINUX copyright.
Linux is (C) Linus Torvalds, but the copyright is the GNU copyleft:
get a copy of the copyleft at your nearest ftp-archive..
7. NEWS ABOUT LINUX
There are now two newsgroups devoted to linux articles: an older
alt.os.linux and the new comp.os.linux group. The alt-group will be
phased out as the comp-group gets a wider propagation. Additionally,
there are a couple of mailing-lists: linux-activists@niksula.hut.fi is
the original mailing-list, and it now supports sub-threads (notably the
gcc-2 beta-testing list). There is also a linux-standards mailing list
as well as a newsgroup-service for those that can get mail but are
unable to read the newsgroups. For the current status of LINUX, do a
"finger torvalds@kruuna.helsinki.fi".
8. FUTURE PLANS
Work is underway on LINUX version 1.0, which will close some of the
gaps in the present implementation. Various people are currently working
on:
- A more complete virtual filesystem layer
- STREAMS
- Interprocess communication
- IEEE POSIX P1003.1 / P1003.2 compatibility
- more complete SCSI support
If you want to help, mail the various activists or post to the newsgroups.
============================
============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux,alt.os.linux
Subject: Re: Second 0.95a alpha-patch
Summary: include-file changes
Message-ID: <1992Apr5.174430.17408@klaava.Helsinki.FI>
Date: 5 Apr 92 17:44:30 GMT
References: <1992Apr4.144210.17833@klaava.Helsinki.FI>
Organization: University of Helsinki
Lines: 51
I forgot to mention some of the changes this alpha-patch brings to the
user: the kernel include-files have been slightly changed in a couple of
cases, which can result in unexpected behaviour...
a.out.h is now the latest GNU a.out.h, and it seems to have slightly
different magic-number handling than the original 386-minix version I
used for older versions. Without recompiling the kernel with the new
a.out.h, programs linked with the new binutils will not run (unable to
execute binary file errors). This just means that even if you don't use
the patch in any other capacity, you had better upgrade to the new
a.out.h, or newer programs won't necessarily run. Right now there are
no such binaries available, but when gcc2 gets more used, they will show
up.
The other change is that limits.h and sys/dirent.h are now part of the
kernel include-files: they were needed for the readdir() system call.
Normally this wouldn't change anything, but there is also a slight
change in limits.h - NAME_MAX is now defined to be 255 so that linux
will eventually handle filesystems with longer names than 14 chars.
This means that the old direntry-routines in the library won't compile
correctly, as they depended on NAME_MAX being the size of a directory
name. I hope the gcc-2 library won't have this problem, and that we can
move over to the more general readdir-function without undue growing
pains.
The a.out.h change was made just to minimize the differences between the
linux headers and the library headers - but the second change is pretty
fundamental. If you are porting software with the old libraries, I'd
suggest keeping to the old limits.h in /usr/include - that way nothing
should break until we get non-minix filesystems. Adventurous people
might want to test out the new kernel functions that will be supported
even with new filesystems.
In case anyone is wondering why the NAME_MAX change is needed, it's due
to the fact that the old /library/ readdir only handled a 14-char
library entry. When the VFS code is enhanced to allow different
filesystems, you no longer can depend on this, and the library routine
wouldn't know what type of directory it's supposed to read - so the code
has to be moved into the kernel which knows about these things. The new
readdir() will work correctly independently of the underlying filesystem
(so that you can freely mix different filesystems without needing to
bother about it).
I'm sorry all this is certain to cause it's share of confusion (using
the old library with the new NAME_MAX and vice versa), but there wasn't
any graceful way to handle it all - unless I would have anticipated
these problems from the start, which I didn't... You can console
yourselves with the thought that linux should be able to handle longer
filenames and >64MB partitions within a couple of releases.
Linus
===========================
===========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: linux-0.95c known bugs
Summary: well, it was alpha...
Message-ID: <1992Apr8.090321.7673@klaava.Helsinki.FI>
Date: 8 Apr 92 09:03:21 GMT
Organization: University of Helsinki
Lines: 58
Well, only one known bug so far, but a couple of problems. I thought I'd
mention them before anyone else does, and we'll call them "features" :^)
The BUG:
when using the readdir() system call, linux incorrectly doesn't let go
of the last buffer used for reading: this results in the buffer being
marked as used (and if you use readdir() heavily, the counter will
eventually wrap around, which might result in incorrect marking as
"not used"). This bug happily isn't easy to find: no current binary
uses the readdir() system call unless you have gotten your hands on
the new VFS gcc-2.1 release. Thanks to Remy Card for finding this
one.
Not too bad a bug though: the fix is very easy. Add a 'brelse(bh);'
in the minix_readdir() function, like this:
if (i) {
put_fs_long(de->inode,&dirent->d_ino);
put_fs_byte(0,i+dirent->d_name);
put_fs_word(i,&dirent->d_reclen);
return i;
should really be :
if (i) {
put_fs_long(de->inode,&dirent->d_ino);
put_fs_byte(0,i+dirent->d_name);
put_fs_word(i,&dirent->d_reclen);
+ brelse (bh);
return i;
That is, just add the brelse before the early return. Sorry for the
lack of real cdiffs - I'm not at home right now, and the above was
taken directly from the bug-report mail.
The problems:
I've had one report that the floppy-driver in versions 0.95x breaks
when accessing drive nr 2. It doesn't on my machine, but I'd
appreciate it if people would test it out, and mail me about any
problems. So far, only one report, but that's one too many.
0.95c doesn't correctly keep track of the 'rss' field in the
task-structure. A fix was already posted (and nothing breaks even if
you don't apply the fix - ps just gives slightly incorrect output)
And the expected troubles with the change of 'a.out.h' - the old gdb
doesn't recognize new executables etc.
As soon as I get my own sources cleaned up, I'll send out a new binary
for the 0.95c+ kernel to the ftp-sites. I've gotten a few mails from
people unable to recompile everything - either because of lack of
diskspace or some other problem. Tomorrow I'll put the new kernel image
on nic.funet.fi and tsx-11 - it's basically the 0.95c kernel + the above
bugfix + the lp-patches (somewhat edited by me).
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux,alt.os.linux
Subject: Re: Large disk partition
Message-ID: <1992Apr8.122049.20594@klaava.Helsinki.FI>
Date: 8 Apr 92 12:20:49 GMT
References: <1992Apr7.202208.12193@spuddy.uucp>
Organization: University of Helsinki
Lines: 40
In article <1992Apr7.202208.12193@spuddy.uucp> sweh@spuddy.uucp (Stephen Harris) writes:
>Is it possible for Linux to use a disk partition greater than 64Mb ?
>I have a 650Mb disk at 1283x16x63. DOS takes up the first 1023 clinders
>(the most it can have), leaving me 128Mb as a second partition. But when I
>try mkfs it moans for greater than 64Mb :-(
Yes, the 64MB limit is still there in the filesystem: it seems the VFS
functions start to get complete soon, but I haven't written any actual
code for any other fs-type. I'll be adding an "extended-minix" type
soon - it will conform to the native-order-long minix filesystem type,
which allows bigger disks, but still has the 14-character name limit (in
case someone wonders why keep to minix types: it's easy to add, as I can
use most of the old routines anyway, and some misguided persons use
linux and minix side by side :)
>Alternatively, could I make this into an extended partiton, with 2x64Mb
>in that, or even 1x10Mb (root+tmp), 1x12Mb(swap=3xRAM),1x64 (/usr), 1x42 (think
>of something!).
As you report you have 0.95c running, it should be safe to use extended
partitions, but the old fdisk probably has problems with them still. At
least I haven't heard any reports of problems with extended partitions
yet, although I haven't heard any success-stories either.
There are other fdisks than the linux or dos ones - pfdisk etc is
reported to work. I haven't got any personal experience (I should be so
lucky to have the 1024-cylinder problem :). Anyway, linux 0.95c should
report any partitions it finds at bootup (along with some data on size
and position), and you should check the numbers before using extended
partitions the first time.
If the bootup-information seems to be ok, try out the extended
partitions (but back up just in case...).
>Help please! I am on 0.95c (yippeee! I successfully managed to get Linus's
>patches to work! Well the kernel boots :-) ).
Is everybody this surprised when one of my patches happen to work? :^)
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Job Ctrl && $$->programmers (How?)
Keywords: jobs, money, bash, happy
Message-ID: <1992Apr9.144903.19540@klaava.Helsinki.FI>
Date: 9 Apr 92 14:49:03 GMT
References: <83443@bu.edu>
Organization: University of Helsinki
Lines: 73
In article <83443@bu.edu> buckley@csa.UUCP (David Buckley) writes:
>
> Is there some version of jsh, or some implementation of the
>functions fg, bg, %[n] etc... I didn't find them on the version of
>bash I am using. Are there several versions of bash? How do we get
>access to job ctrl? I know these exist from reading previous
>postings, are they hiding or should I chmod u+rwx mybrain.out?
Yes, there are several versions of bash existing - some of them are
/very/ old. I don't know if the original bash.Z is still somehwre to be
found, but it was not too long ago, and that is the version I used under
0.01, long before linux had job control. That version certainly doesn't
support job control.
Versions of bash that support job control (including the builtins fg,
bg, kill, jobs etc) are available on older root-disks, notably the 0.95
(not "a") rootdisk. I don't know where to find a "standalone" version
of bash - I know somebody ported bash 1.12 (the one on the rootdisk is
1.11 patch-level 1, although I think "help" returns 0.00.1).
You might want to check out the abc-release when it gets out - right now
the binaries under linux are a major mess (different versions under the
same name etc...), but this will eventually be sorted out, I hope.
> Also, is there some list of developers-port|ers so that
>it might be easyer to direct financial contributions to this venture?
>I haven't seen any postings with regards to how and to who money
>should be donated, and I think it would be interesting to be able
>to direct donations for specific implementations (our unix favourites),
>beyond Linux itself. Such a posting (I feel) would be greately
>appreciated.
I have never felt anybody needed to pay for linux - I didn't want to
make it share-ware, and I never wanted to make it commercial. The
biggest reason I started on linux at all was that I had no good unix and
no money - I wanted a totally free unix (not "GNU-free", but "no-money"
free - the "GNU-free" came later). I still have no money, but at least
I've got the unix :)
In fact, the earliest copyrights expressly forbid /any/ money at all
changing hands due to linux - the above was the reason. As the system
actually became useable, I had to change my mind - I don't mind people
making money off linux, as long as it essentially is available for free
as well, which it is.
I still feel strongly about the money-thing though - I don't want to
encumber the "official" version with any kind of pleas for money. If I
had something like "if you enjoy this package, please send $10 to xxx"
it might scare away people from then sending other feedback (bugreports
etc), as they didn't send the money... As it is, linux has no special
"registered users" which get special treatment by me - if you are
porting something important, I might give your troubles more thought
than the average user, but I try to answer every problem that gets
reported (even if it's just a "sorry, can't help this one" or "it's a
known problem, I don't know the cure", "hardware dependant").
One thing I would appreciate is people sending me postcards from all
over the world: I don't want to be a new Craig Shergold, but it might be
fun to see where linux is used :^). Postcards (with least name and
location written in for reference) could be sent to:
Linus Torvalds
Pietarinkatu 2 A 2
00140 Helsinki
Finland
and maybe I'll wallpaper my room with them :). Or maybe not.
Linus
PS. If you have contacts with hardware suppliers, and would like to get
things like multi-serial cards/tape streamers etc supported... I just
might be persuaded to try it out :-)
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Another bug?
Message-ID: <1992Apr10.203916.27326@klaava.Helsinki.FI>
Date: 10 Apr 92 20:39:16 GMT
References: <1992Apr8.090321.7673@klaava.Helsinki.FI> <1992Apr9.200244.28901@wam.umd.edu>
Organization: University of Helsinki
Lines: 24
In article <1992Apr9.200244.28901@wam.umd.edu> joel@wam.umd.edu (Joel M. Hoffman) writes:
>In article <1992Apr8.090321.7673@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>>Well, only one known bug so far, but a couple of problems. I thought I'd
>>mention them before anyone else does, and we'll call them "features" :^)
>
>More than once, I've gotten a message about mis-linked processes. I
>usually get it when I'm compiling from one VC and using Kermit
>interactively on another, but most of the time I'm compiling and using
>Kermit....
The mis-linked process problem seems to be linked with swapping: I've
never seen it, and most (all?) that have reported it have only 2M ram -
it seems to be a race-condition in the exit code, that breaks while
swapping heavily. I think that running gcc and kermit on a 2M system
should be enough to swap quite a bit...
I have fixed some of the exit-code in 0.95c+ - I'd be very interested to
hear if this problem is gone with the new kernel. The exit-code was
"interesting" - I think tytso optimized the sibling linking a bit too
much, and it broke when paging meant that the kernel sleeps in some new
circumstances. I might be totally off base - apologies to tytso if I
am.
Linus
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: kernel building problems
Message-ID: <1992Apr11.095724.8928@klaava.Helsinki.FI>
Date: 11 Apr 92 09:57:24 GMT
References: <1992Apr10.153857.28399@CSD-NewsHost.Stanford.EDU> <1992Apr10.162906.21379@ods.com>
Organization: University of Helsinki
Lines: 20
In article <1992Apr10.162906.21379@ods.com> david@ods.com (David Engel) writes:
>
>Aside to Linus: Would you mind describing how you have your system set
>up? It might help aleviate problems like this if we knew which compiler
>and system libraries you are using.
I'm still using 2.0 (and an older version at that) as I've been too busy
to upgrade. I doubt the HJ-patch is really needed - I read through it,
and I'd guess 0.95c+ should compile pretty cleanly without it. Anybody
tried it? HJ's patch also assumes you have a 387, and you'll have to
edit the makefile if you don't.
I'll have to upgrade my compiler (probably this weekend), and the next
real version should have no problems with 2.1. I'm in fact still using
my original 1.40 for everything but the kernel - I've left the actual
beta-testing of the new compilers and libraries to everyone else, and
I'll step in now that they seem stable. Lazyness or prudency, you
decide :)
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux,alt.os.linux
Subject: Re: more on my problem(I still haven't got any help) : )
Message-ID: <1992Apr17.080304.20001@klaava.Helsinki.FI>
Date: 17 Apr 92 08:03:04 GMT
References: <1992Apr15.232024.23565@athena.mit.edu>
Organization: University of Helsinki
Lines: 21
In article <1992Apr15.232024.23565@athena.mit.edu> jgifford@attmail.com writes:
>Ok, here goes:
>I had xcomm, it was running fine. suddenly, it started outputting to the
>screen 2 cr/lf for every one I hit on the keyboard. I went into kermit
>to see if it was xcomm, or the place I am calling. kermit was doing
>this:
>C-Kermit>set line /dev/ttys4
>
>C-kermit> set speed 2400
At least the double-spacing in kermit is due to login first enabling
ECHONL on the tty for the password recognition (it naturally wants no
echo on normal characters, but wants the newline to be echoed), and it
doesn't disable it afterwards. This doesn't result in any problems for
most things, but some programs (at least my port of kermit) seem not to
notice it: kermit disables echoing, but doesn't disable the ECHONL.
The cure for kermit is to write "stty -echonl" in your .profile or
similar - I don't know if this helps xcomm as well.
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 850 gig extended*2 partition on 300 meg drive? ;-)
Message-ID: <1992Apr20.055129.21246@klaava.Helsinki.FI>
Date: 20 Apr 92 05:51:29 GMT
References: <k-4jgjf.xtifr@netcom.com>
Organization: University of Helsinki
Lines: 18
In article <k-4jgjf.xtifr@netcom.com> xtifr@netcom.com (Chris Waters) writes:
>
>Truly inconsequential, but I thought y'all might find this amusing. I
>just tried the .95c+ bootimage out at tsx-11 (I had been using .95a),
>and all of a sudden I get the following report from fdisk:
[ "somewhat" erraneous output deleted ]
The old fdisk messes up extended partitions (as did the old kernel), and
shouldn't be used. Not that it does any harm, as the old fdisk only
reads from the disk, but as you saw, it doesn't exactly give good
results.
With 0.95c+, the available partitions are reported at bootup, so the
need for a fdisk is less, but I hope the next release will contain one
that works correctly.
Linus
================================
================================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: gdb still isn't working
Message-ID: <1992Apr20.085143.23027@klaava.Helsinki.FI>
Date: 20 Apr 92 08:51:43 GMT
References: <Apr.19.22.23.03.1992.17499@dumas.rutgers.edu>
Organization: University of Helsinki
Lines: 35
In article <Apr.19.22.23.03.1992.17499@dumas.rutgers.edu> hedrick@dumas.rutgers.edu (Charles Hedrick) writes:
>I've been trying to get gdb working. The problem is more subtle than
>I had first thought. It worked fine up to 0.95b. However as of 0.95c
>and 0.95c+, it stopped working.
Yes, it's a bug in the kernel. It was there already in 0.95b and
earlier, but those had a (buggy) workaround that made it work for most
things anyway. The problem was that not all kernel mode -> user mode
changes checked the error conditions, so things like breakpoints didn't
work too well.
My personal version handles this correctly (as well as doing some other
things in a cleaner manner), but I'm not quite ready for a new release
yet. I could make YAAR (yet another alpha-release) or just mail
interested parties the fixes needed - mail me if you're interested, and
depending on the number of messages I get I'll make it a new release.
Here's a preview of 0.96 (* means already implemented):
* truncate/ftruncate/fchmod/fchown system calls
* io-bitmap allowing user processes controlled access to io-ports (thanks to
obz - needed for X)
* mmap for /dev/mem - (thanks to obz) allows X etc to use the frame buffers
* the signal-handling fixes needed for gdb
- multiple shared libraries (pmacdona)
- cleaned up special files: partly implemented already
and probably some other minor fixes.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux,alt.os.linux
Subject: pre-0.96 (was Re: gdb still isn't working)
Message-ID: <1992Apr21.231510.5903@klaava.Helsinki.FI>
Date: 21 Apr 92 23:15:10 GMT
References: <Apr.19.22.23.03.1992.17499@dumas.rutgers.edu> <1992Apr20.085143.23027@klaava.Helsinki.FI>
Organization: University of Helsinki
Lines: 128
In article <1992Apr20.085143.23027@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
> [ trace not working in gdb ]
>
>My personal version handles this correctly (as well as doing some other
>things in a cleaner manner), but I'm not quite ready for a new release
>yet. I could make YAAR (yet another alpha-release) or just mail
>interested parties the fixes needed - mail me if you're interested, and
>depending on the number of messages I get I'll make it a new release.
Ok, the response seems to make a new pre-release appropriate: I have
uploaded "pre-0.96.tar.Z" to tsx-11 and nic.
Here is what the pre-release contains:
- truncate/ftruncate/fchmod/fchown system calls
note that there aren't any library functions for these, so they
aren't very useful yet...
[f]truncate needed a change in the logic of the internal
truncate VFS call - anybody that has any nonstandard filesystem
probably needs to look it up.
- io-bitmap syscalls giving root-processes access to selected io ports
from user space. There is a "ioperm()" system call that lets the
process select which ports it wants to enable/disable (all ports
disabled as default) as well as a (standard sysv?) ioctl interface
that X uses.
again, no library stubs, but it allows things like reading and
setting the cmos clock without using /dev/port, as well as
control over the VGA registers...
- mmap for /dev/mem
more things needed for X...
- the signal-handling fixes needed for gdb
These aren't yet complete: serial lines still send signals under
interrupts that can result in problems (ie ptrace doesn't
correctly get them), but that's pretty unlikely (and will be
fixed in the final 0.96). Breakpoints should work etc..
- multiple shared libraries
Up to 6 simultaneous shared libraries/process: the patches were
originally by pmacdona, but they were heavily changed by me, and
I think they work in a more natural manner now. One user-level
change is that the libraries are now checked for read and
execute permissions for safety-reasons.
- cleaned up special files.
read/write/ioctl no longer has special-case code: it is all
handled with tables to functions. This will mean that the SCSI
patches won't patch in quite cleanly into 0.96: you'll need to
add the code that sets up the functions.
Again: device drivers and vfs-filesystem hackers need to look
into the changes, although they are pretty logical (earlier
versions just didn't implement all the vfs-routines)
Note that the vfs-code for select is still not used: select is
hardcoded for the devices it supports right now.
- ptrace() has a new interface
as gdb for versions < 0.95c don't work on the new version, and
gdb won't work very well at all on 0.95c[+], there was no reason
not to break ptrace. Thus 0.96 has a new calling convention for
ptrace, and the old ptrace library function no longer works.
I'm including the new ptrace library function at the end of this
post.
- mount() takes 4 arguments, and checks that only the super-user can
mount/umount things.
Happily this shouldn't break any old binaries.
- some general cleanups
I've made the pre-release available only as pure source code: no diffs,
no binary. The reason is that most people that needed this release want
it for the gdb-fixes: and they should have no problem recompiling the
kernel. Others just have to wait for the real 0.96.
Changes that are NOT in this pre-release, but which I hope to have in
the real 0.96:
- more include-file cleanups - I'm still working on these
- the wd8003 driver and hopefully some other parts of biro's
config.
- select() using the vfs-tables.
And possibly bugfixes that people find in this pre-release...
Linus
---------- library ptrace.c (wants gcc-2.1) ----------
#define __LIBRARY__
#include <time.h>
#include <unistd.h>
int ptrace(int request, int pid, int addr, int data)
{
long ret;
long res;
if (request > 0 && request < 4)
(long *)data = &ret;
__asm__ volatile ("int $0x80"
:"=a" (res)
:"0" (__NR_ptrace),"b" (request), "c" (pid),
"d" (addr), "S" (data)
: "si","bx","cx","dx");
if (res >= 0) {
if (request > 0 && request < 4) {
errno = 0;
return (ret);
}
return (int) res;
}
errno = -res;
return -1;
}
=============================
=============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: How to pronounce "Linux"?
Message-ID: <1992Apr23.123216.22024@klaava.Helsinki.FI>
Date: 23 Apr 92 12:32:16 GMT
References: <1992Apr23.044317.3916@nuscc.nus.sg>
Organization: University of Helsinki
Lines: 25
In article <1992Apr23.044317.3916@nuscc.nus.sg> npngps@solomon.technet.sg (Ng Pheng Siong) writes:
>I apologize if this is considered trivial, but what is the
>proper pronunciation for "Linux"?
>
>Li lee or lie?
>Nux nuks or nerks? Nooks?
Oh god. We just hashed this through on alt.os.linux. It /definitely/
needs to go into the FAQ.
'li' is pronounced with a short [ee] sound: compare prInt, mInImal etc.
'nux' is also short, non-diphtong, like in pUt. It's partly due to
minix: linux was just my working name for the thing, and as I wrote it
to replace minix on my system, the result is what it is... linus' minix
became linux.
I originally intended it to be called freax (although buggix was one
contender after I got fed up with some of the more persistent bugs :)
and I think the kernel makefiles up to version 0.11 had something to
that effect ("Makefile for the freax kernel" in a comment). But arl
called the linux directory at nic.funet.fi pub/OS/Linux, and the name
stuck. Maybe just as well: freax doesn't sound too good either (freax
is obviosly free + freak + the obligatory -x).
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: gdb fails on ioctl??
Keywords: gdb ioctl
Message-ID: <1992Apr24.215331.16846@klaava.Helsinki.FI>
Date: 24 Apr 92 21:53:31 GMT
References: <1992Apr24.085616.29705@cbnewsd.cb.att.com> <1992Apr24.163555.26570@watson.ibm.com>
Organization: University of Helsinki
Lines: 27
In article <1992Apr24.163555.26570@watson.ibm.com> rajat@watson.ibm.com (Rajat Datta) writes:
>I'm getting the same problem. It's related to the under debugging
>process doing a read from the tty. I guess gdb is doing TIOCSPGRP to
>set the tty process group to be the same as the process under debug to
>avoid the stopped input message, but the tty ioctl code is rejecting
>it because the current process (gdb) does not have the same process
>group as the one we're setting the tty to (the under debug process).
Right. The easy fix if to comment out the session testing in
tty_ioctl.c: right after the "case TIOCSPGRP:" comment out the two
lines
if (session_of_pgrp(pgrp) != current->session)
return -EPERM;
and gdb should be happy. The session_of_pgrp() code has problems (I
think I've fixed them now, though).
>I would appreciate a solution. Except for this, gdb works fine under
>95c++ and is an indispensable tool.
My version already has this fixed (not the above quick hack - another
not-quite-as-ugly hack that might even be correct), and the real 0.96
(out next week? maybe) won't have the above problems. In the meantime,
just dike out the two lines.
Linus
==================
==================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: swapfile on scsi?
Keywords: does it work?
Message-ID: <1992Apr25.182734.6720@klaava.Helsinki.FI>
Date: 25 Apr 92 18:27:34 GMT
References: <55716@hydra.gatech.EDU>
Organization: University of Helsinki
Lines: 22
[ swapon problems ]
Ok, I thought I'd mentions this here, as I seem not to have done it in
the readme's. After doing a "mkswap", it's best to sync the filesystem:
swapping doesn't use the buffer cache, so before doing a swapon you
should make sure the swap-space signature and ID bitmaps are correctly
flushed out to the disk.
Note that the above shouldn't result in any filesystem problems even if
you don't sync: the block numbers are still gotten through the
filesystem routines. It's just the data blocks themselves that are
loaded with no regard for buffer cache coherency, as it makes little
sense to keep swap data in the buffer cache. This is normally no
problem, but for the fact that the first page (4 blocks) of the swapfile
contains the signature, and is loaded with the normal swap-routines.
The result is that if you see "swap space signature not found" or
similar errors, it might be a good idea to sync, wait a bit for it to
complete, and then try swapon again. Swapon should probably do an
implicit sync, but I didn't think of it when I wrote it.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: My pre-0.96 won't run shared binaries
Message-ID: <1992Apr27.083131.23100@klaava.Helsinki.FI>
Date: 27 Apr 92 08:31:31 GMT
References: <JES.92Apr24145256@mbio.med.upenn.edu> <JES.92Apr26171522@mbio.med.upenn.edu>
Distribution: comp
Organization: University of Helsinki
Lines: 22
In article <JES.92Apr26171522@mbio.med.upenn.edu> jes@mbio.med.upenn.edu (Joe Smith) writes:
>
>Well, I'm straight now on the ps patches, but it seems I was wrong
>about pre-0.96 running ok: even a clean kernel refuses to run
>shared-lib binaries, even 'hello.c', for a non-root user. They all
>die with an 'invalid operand... segmentation fault'.
Ok, if it works for root, the problem is probably the permissions for
the shared library: check that /lib/libXXXX is both readable and
executable by the user (and if you have a symlink, check that the file
it points to is read/executable)
Earlier versions didn't check for read/exec permissions, which is an
obvious security problem: under 0.95c+ and earlier, you could
effectively do a "uselib(XXXX)", and be able to read the file XXXX
(except for the 1024 first bytes) by reading memory at 0x03c00000- in
your process space. 0.96 (even the pre-version) checks the header of
the file, and the permissions, to make sure you are trying to use a real
library file that you have access to, so that this kind of thing
wouldn't be possible.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: are raw floppy blocks kept in the buffer pool?
Message-ID: <1992Apr29.064505.23303@klaava.Helsinki.FI>
Date: 29 Apr 92 06:45:05 GMT
References: <JES.92Apr28193232@mbio.med.upenn.edu>
Distribution: comp
Organization: University of Helsinki
Lines: 21
In article <JES.92Apr28193232@mbio.med.upenn.edu> jes@mbio.med.upenn.edu (Joe Smith) writes:
>
>I was using tar to attempt a backup last night & noticed that after
>tar finished and I removed the floppy, the drive light came back on
>(of course that means the Linux is OTL until you put a floppy back in
>the drive, and I have no idea whether it was reading or writing). It
>made me wonder whether blocks written to a raw floppy device are
>buffered by the kernel and if so, whether this is a ``good thing''.
Yes, the raw devices are implemented on top of the buffer cache: a
close() does an automatic sync. It's not standard, but it was easy to
implement. It might be the reason why tar doesn't like to use
multiple-disk backups on linux: although if you close the device and
open it again at a disk-change there should be no problem. Does tar do
this or just a lseek(0)?
Linus
PS. A simple fix is to do a "ll_rw_block(WRITE,bh)" in the block-device
write function: I just did it, so 0.96 won't keep dirty blocks around at
all. Reading still uses the buffer cache, though.
============================
============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Offical windows
Message-ID: <1992Apr29.091015.27476@klaava.Helsinki.FI>
Date: 29 Apr 92 09:10:15 GMT
References: <08VwJB5w161w@grafted.UUCP> <4992@umriscc.isc.umr.edu> <1992Apr29.070932.25201@mnemosyne.cs.du.edu>
Organization: University of Helsinki
Lines: 34
In article <1992Apr29.070932.25201@mnemosyne.cs.du.edu> zmbenhal@isis.cs.du.edu (Zeyd M. Ben-Halim) writes:
>
>Well, linus has just said on comp.os.minix that X WORKS but is not to be
>released to the "masses" yet!
Don't take it too hard: I'm also part of "masses" - I haven't seen it
working on my own machine yet... obz has been porting it for a longish
time (started with the advent of 0.12 I think), and I don't know how
many problems still remain (not too long ago he still had trouble
returning to character mode after X exited etc). He's sent me mail that
he edited in an xterm under linux though, so it's getting there...
Some of the results are already visible in the pre-0.96 release: the
mmap code and the io-port control needed for it. The socket code is
still not ready: the socket-emulation library on top of pty's had
problems, as the pty's aren't complete (they don't support hanging up
etc yet).
>The question is WHY NOT? Even if it is not working properly, couldn't we at
>least hear about the effort involved in porting X (setting modes, reading,
>writing to the screen memory, switching banks, etc.)
I assume obz is nearing completion and alpha-testing: he created a X11
channel on the original mailing list. Not that there has been any
activity yet :-)
I also assume one reason we haven't heard too much about graphics under
linux is simply because X11r5 (with the free X386 server) does all the
mode-setting things by itself, and doesn't need the kernel to do that
much. So porting X doesn't help other graphical systems that much: it's
mainly a question of getting the same kind of support as "normal"
386-unixes allow X, ie mmap/sockets etc.
Linus
===========================
===========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: alt.os.linux,comp.os.linux
Subject: Re: Disk drive performance
Message-ID: <1992Apr29.091828.27784@klaava.Helsinki.FI>
Date: 29 Apr 92 09:18:28 GMT
References: <1992Apr28.220324.25222@spuddy.uucp>
Organization: University of Helsinki
Lines: 15
Ok, as several people have written about bad IO performance, I decided
to finally do some of the simplest optimizations possible under linux,
so 0.96 will be a bit snappier when copying large files etc. Under very
extreme circumstances, IO speeds are now 10 times faster according to my
simple tests, but that's just "marketing info": most things are still
about the same speed.
None of the optimizations are in the driver proper: I just finally
implemented read-ahead on files, and used the ps-patch that gives IO
bound processes more time. Thus the speed-increase is most noticeable
when you do something else in the background. I also changed sync a bit
so that it doesn't wait around quite so much. Expect a slightly more
responsive system, but no major changes.
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Latin-1 again
Message-ID: <1992Apr30.075826.7201@klaava.Helsinki.FI>
Date: 30 Apr 92 07:58:26 GMT
References: <1992Apr23.205017.6569@casbah.acns.nwu.edu> <JEM.92Apr30092141@sandman.hut.fi>
Organization: University of Helsinki
Lines: 19
In article <JEM.92Apr30092141@sandman.hut.fi> jem@niksula.hut.fi (Johan Myreen) writes:
>
>A while ago I posted patches to the keyboard driver so it could
>produce Latin-1 characters. I never uploaded the patches, and they
>don't work with current versions anyway. I'll dig them up and see what
>needs to be done for the current version.
I actually used the patches to some degree: I didn't use the keyboard
patches, but I used the console-part, so linux pre-0.96 tries to do
8-bit latin1 printing. To some degree. I haven't tested it, as I don't
have anything that uses the 8-bit characters, but it does seem to print
out most of the correct characters. Try something like
$ echo -e "\241"
and you should get a inverted "!". It might even have been in 0.95c+, I
dunno.
Linus
=============================
=============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 0.96 out next week
Message-ID: <1992May4.073803.3222@klaava.Helsinki.FI>
Date: 4 May 92 07:38:03 GMT
References: <1992May4.055329.17266@mnemosyne.cs.du.edu>
Organization: University of Helsinki
Lines: 61
Ok, the subject says most of it: I'll send out 0.96 sometimes next week
(ie 92.05.11-17), and this is just an announcement to confirm that.
0.96 has a lot of changes (even relative to pre-0.96), and it's entirely
possible that making it available as cdiffs isn't feasible. It contains
a lot of new files, as well as some re-organizations in the old ones.
Main new things are:
- The SCSI distribution is now in the standard package. I (obviously)
haven't been able to test my patchings, so there might be problems in
this first release. I had to do some changes "blind" to the cdiffs,
but most of them were pretty trivial.
- X11r5 as ported by obz is supported. It's still in beta-testing (join
the X11-channel on the original mailing-list), but as I'm writing this
from an xterm under linux, it works pretty well. Changes to pre-0.96
are just the socket-code by obz, and some small tweaking by me.
- Hopefully better interrupt latency - I've changed select() not to use
cli-sti, and most IRQ's to enable interrupts, and instead disable just
their own interrupt-line. The interrupt latency has been noticeable at
higher serial speeds, and I hope 0.96 will be better in this respect.
Again, I only have 2400bps, so I've never seen the problems, and
cannot guarantee the new version will help. (btw, I hope the problems
with select are gone now)
- Reorganisation of the vfs routines and minix filesystem driver. These
shouldn't bother anyone but people that have implemented their own
filesystems (I know of just 2 to date), but I hope the current
vfs-interface will prove to be relatively stable. The new vfs
interface has made some things much cleaner, and the promised cleanup
of special devices has happened.
- ps/uptime patches + added readahead, so having computationally
intensive background processes isn't as noticeable any more when doing
IO.
Additionally, there /might/ be a new floppy-driver that supports
formatting and autodetecting floppies, but I haven't had time to check
into it yet.
There are probably any number of minor changes: I've lost track. People
have sent me some diffs, and some of them went in, depending on how
energetic I was that day. I've tried to correct all the bugs I've
gotten reports on, and hopefully 0.96 will work with just about
everything (gdb etc).
Things I wanted, but didn't have time for:
- The config patches aren't there. Sorry everybody. That means still no
wd8003 driver etc.
- Any number of minor patches (quota, auto-SVGA etc)
Generally, 0.96 is cleaning some things up, but on the other hand the
new features can have their share of problems. We'll see. Anyway, most
things seem to work, and I hope there won't be the same type of problems
as with the first 0.95 release.
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: X386 (Was Re: 0.96 out next week)
Message-ID: <1992May5.063513.11484@klaava.Helsinki.FI>
Date: 5 May 92 06:35:13 GMT
References: <1992May4.055329.17266@mnemosyne.cs.du.edu> <1992May4.073803.3222@klaava.Helsinki.FI> <1992May5.00552.26728@ms.uky.edu>
Organization: University of Helsinki
Lines: 28
In article <1992May5.00552.26728@ms.uky.edu> randy@ms.uky.edu (Randy Appleton) writes:
>> [ X window system ]
>
>Here's a question. What CGA cards does it support, and at what
>resolutions. Also, what's the realistic RAM requirements?
X definitely won't work with CGA - it won't even work with normal VGA
cards: you need SVGA (and even not just any SVGA card will do). The
supported cards are et[3|4]000 and some others (pvga? tvga?).
Resolutions range from 640x480 to 1192x900 (or something like that), all
at 256 colours, depending on what kind of card/monitor combination you
have.
As to memory: I'm using it in 8MB ram, and no swapping (with a couple of
xterms, xclock and xcalc - nothing major). If I want to recompile the
kernel in an xterm, I'll have to start up swapping (well, actually I've
done it without swapping, but it's tight). I assume it's still useable
in 4MB and a big swap-file, but I'm happy I haven't tested it.
Speed probably depends heavily on the SVGA card: on my 386/33 with a
no-name et4000 card I get totally acceptable performance: scrolling big
windows is slow with other things going on, but not irritatingly so.
You don't want to make opaque moves, but I can live without that.
Harddisk space is totally up to you: minimum about 10MB for just the
minimal clients, maximum probably the sky is the limit.
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Writing an OS - questions !!
Message-ID: <1992May5.075817.15984@klaava.Helsinki.FI>
Date: 5 May 92 07:58:17 GMT
References: <10685@inews.intel.com>
Organization: University of Helsinki
Lines: 136
In article <10685@inews.intel.com> nani@td2cad.intel.com (V. Narayanan) writes:
>
>Hi folks,
> For quite some time this "novice" has been wondering as to how one goes
>about the task of writing an OS from "scratch". So here are some questions,
>and I would appreciate if you could take time to answer 'em.
Well, I see someone else already answered, but I thought I'd take on the
linux-specific parts. Just my personal experiences, and I don't know
how normal those are.
>1) How would you typically debug the kernel during the development phase?
Depends on both the machine and how far you have gotten on the kernel:
on more simple systems it's generally easier to set up. Here's what I
had to do on a 386 in protected mode.
The worst part is starting off: after you have even a minimal system you
can use printf etc, but moving to protected mode on a 386 isn't fun,
especially if you at first don't know the architecture very well. It's
distressingly easy to reboot the system at this stage: if the 386
notices something is wrong, it shuts down and reboots - you don't even
get a chance to see what's wrong.
Printf() isn't very useful - a reboot also clears the screen, and
anyway, you have to have access to video-mem, which might fail if your
segments are incorrect etc. Don't even think about debuggers: no
debugger I know of can follow a 386 into protected mode. A 386 emulator
might do the job, or some heavy hardware, but that isn't usually
feasible.
What I used was a simple killing-loop: I put in statements like
die:
jmp die
at strategic places. If it locked up, you were ok, if it rebooted, you
knew at least it happened before the die-loop. Alternatively, you might
use the sound io ports for some sound-clues, but as I had no experience
with PC hardware, I didn't even use that. I'm not saying this is the
only way: I didn't start off to write a kernel, I just wanted to explore
the 386 task-switching primitives etc, and that's how I started off (in
about April-91).
After you have a minimal system up and can use the screen for output, it
gets a bit easier, but that's when you have to enable interrupts. Bang,
instant reboot, and back to the old way. All in all, it took about 2
months for me to get all the 386 things pretty well sorted out so that I
no longer had to count on avoiding rebooting at once, and having the
basic things set up (paging, timer-interrupt and a simple task-switcher
to test out the segments etc).
>2) Can you test the kernel functionality by running it as a process on a
> different OS? Wouldn't the OS(the development environment) generate
> exceptions in cases when the kernel (of the new OS) tries to modify
> 'priviledged' registers?
Yes, it's generally possible for some things, but eg device drivers
usually have to be tested out on the bare machine. I used minix to
develop linux, so I had no access to IO registers, interrupts etc.
Under DOS it would have been possible to get access to all these, but
then you don't have 32-bit mode. Intel isn't that great - it would
probably have been much easier on a 68040 or similar.
So after getting a simple task-switcher (it switched between two
processes that printed AAAA... and BBBB... respectively by using the
timer-interrupt - Gods I was proud over that), I still had to continue
debugging basically by using printf. The first thing written was the
keyboard driver: that's the reason it's still written completely in
assembler (I didn't dare move to C yet - I was still debugging at
about instruction-level).
After that I wrote the serial drivers, and voila, I had a simple
terminal program running (well, not that simple actually). It was still
the same two processes (AAA..), but now they read and wrote to the
console/serial lines instead. I had to reboot to get out of it all, but
it was a simple kernel.
After that is was plain sailing: hairy coding still, but I had some
devices, and debugging was easier. I started using C at this stage, and
it certainly speeds up developement. This is also when I start to get
serious about my megalomaniac ideas to make "a better minix that minix".
I was hoping I'd be able to recompile gcc under linux some day...
The harddisk driver was more of the same: this time the problems with
bad documentation started to crop up. The PC may be the most used
architecture in the world right now, but that doesn't mean the docs are
any better: in fact I haven't seen /any/ book even mentioning the weird
386-387 coupling in an AT etc (Thanks Bruce).
After that, a small filesystem, and voila, you have a minimal unix. Two
months for basic setups, but then only slightly longer until I had a
disk-driver (seriously buggy, but it happened to work on my machine) and
a small filesystem. That was about when I made 0.01 available (late
august-91? Something like that): it wasn't pretty, it had no floppy
driver, and it couldn't do much anything. I don't think anybody ever
compiled that version. But by then I was hooked, and didn't want to
stop until I could chuck out minix.
>3) Would new linkers and loaders have to be written before you get a basic
> kernel running?
All versions up to about 0.11 were crosscompiled under minix386 - as
were the user programs. I got bash and gcc eventually working under
0.02, and while a race-condition in the buffer-cache code prevented me
from recompiling gcc with itself, I was able to tackle smaller compiles.
0.03 (October?) was able to recompile gcc under itself, and I think
that's the first version that anybody else actually used. Still no
floppies, but most of the basic things worked.
Afetr 0.03 I decided that the next version was actually useable (it was,
kind of, but boy is X under 0.96 more impressive), and I called the next
version 0.10 (November?). It still had a rather serious bug in the
buffer-cache handling code, but after patching that, it was pretty ok.
0.11 (December) had the first floppy driver, and was the point where I
started doing linux developement under itself. Quite as well, as I
trashed my minix386 partition by mistake when trying to autodial
/dev/hd2.
By that time others were actually using linux, and running out of
memory. Especially sad was the fact that gcc wouldn't work on a 2MB
machine, and although c386 was ported, it didn't do everything gcc did,
and couldn't recompile the kernel. So I had to implement disk-paging:
0.12 came out in January (?) and had paging by me as well as job control
by tytso (and other patches: pmacdona had started on VC's etc). It was
the first release that started to have "non-essential" features, and
being partly written by others. It was also the first release that
actually did many things better than minix, and by now people started to
really get interested.
Then it was 0.95 in March, bugfixes in April, and soon 0.96. It's
certainly been fun (and I trust will continue to be so) - reactions have
been mostly very positive, and you do learn a lot doing this type of
thing (on the other hand, your studies suffer in other respects :)
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: What kernel needed to run X???
Message-ID: <1992May5.191103.4763@klaava.Helsinki.FI>
Date: 5 May 92 19:11:03 GMT
References: <13013@ucdavis.ucdavis.edu>
Organization: University of Helsinki
Lines: 9
In article <13013@ucdavis.ucdavis.edu> mayfield@toadflax.UCDavis.EDU (Doug Mayfield) writes:
>To re-iterate... What version of the kernel is required to
>run X.
You need pre-0.96 with the (pretty small) patches for sockets that are
included with the X distribution. Alternatively, you can wait a week
for the real 0.96, which also fixes a couple of minor problems.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: X386 and lame SVGA cards
Message-ID: <1992May6.220143.13536@klaava.Helsinki.FI>
Date: 6 May 92 22:01:43 GMT
References: <PNAKADA.92May6103934@pnakada.oracle.com> <1992May6.151359@hammer.Prime.COM>
Organization: University of Helsinki
Lines: 36
In article <1992May6.151359@hammer.Prime.COM> cummings@hammer.Prime.COM (Kevin
Cummings) and others write:
> > [ no support for some cards, or even standard 640x480x16, as it's
> > not "worth it" ]
>
>I don't agree with them, but they have the source, and I don't.
Well, in fact you /do/ have source: just get the X11r5 distribution and
hack on it. That's how the original X386 was created (well, it wasn't
based on r5, but you get the idea). The linux X-server certainly isn't
based on any proprietary code.
There seem to be several drivers that implement standard VGA modes (just
look at "real" unixes), but sadly, none of them seem to be freely
distributable, and so aren't part of the standard distribution. The
X386 drivers included are written by Roell, and it's not really fair to
criticize him for not writing drivers for all the possible card
combinations. He did them for free, after all (sadly (for us - I doubt
he minds) he seems now to get paid for his effors, so he no longer makes
them available for no chanrge). If you want to lay the blame somewhere,
do it at IBM who didn't come up with a good standard for video cards.
The reason there doesn't seem to exist any 16-colour drivers for free is
simply because nobody seems to have wanted to write them: 16-colour
programming isn't fun, and the results aren't as pleasing as 256 colour
modes. Not surprisingly, 256 colour mode is more popular. Also, not
surprisingly, chipsets that are easier to program (ie et4000) get the
drivers.
What I'm trying to say is that X386 is free, and that nobody got paid
for producing it: don't be surprised if it doesn't support all hardware.
Even as I'm not going to write a PS2 version of linux (unless somebody
gives me a PS2 + docs etc), I assume roell didn't want to write a
version that he felt was "uninteresting".
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: pre-0.96 & inaccessable memory as non-root
Keywords: segmentation fault
Message-ID: <1992May7.081436.25846@klaava.Helsinki.FI>
Date: 7 May 92 08:14:36 GMT
References: <May.6.23.50.41.1992.27825@pilot.njin.net>
Organization: University of Helsinki
Lines: 21
In article <May.6.23.50.41.1992.27825@pilot.njin.net> pfaffman@pilot.njin.net (Jay Pfaffman) writes:
>
>I installed the pre-0.96 release on two machines and have successfully
>installed it on one of them. On the other, though, no one but root
>can login. I played with changing UID, and found that the first
>memory access after changing to something other than root I get a
>segmentation fault. Have I done something stupid? It works fine on
>another machine. (I'm using it now).
Ok, this is probably the shared libraries that bite you: pre-0.96 added
more sanity checks than earlier versions, and won't load in the shared
libraries unless they are readable and executable by the user. Check
that the shared libraries in /lib/libXX.YY.ZZ all have the correct
permissions.
Due to a bug in the early crt0.s, not being able to load the shared
library results in a segmentation fault: this should be fixed in the
newer gcc-2.1 versions, but programs compiled with the old ones will
fail without any error-message.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Wow! X is great!
Message-ID: <1992May7.174038.16552@klaava.Helsinki.FI>
Date: 7 May 92 17:40:38 GMT
References: <PNAKADA.92May7083854@pnakada.oracle.com>
Distribution: comp
Organization: University of Helsinki
Lines: 51
In article <PNAKADA.92May7083854@pnakada.oracle.com> pnakada@oracle.com (Paul Nakada) writes:
>
>a serious bug. If I pull down the xterm middle menu (control +
>middlebutton (both buttons)) my screen gets shifted ~30% with the
>right side wrapping to the left side. wierd.
Yes, this is one of the bugs that is still in the pre-0.96 release with
the X patches: it's due to the fact that error messages get printed to
the console, and the pre-0.96 kernel didn't notice that things were in
graphics mode, so it prints out the message and changes various VGA
regs, thinking it writes to a normal text-screen. This obviously doesn't
work too well when in garphics mode.
Other bugs relate to the pty's: when scrolling in an xterm it sometimes
stops, and you have to hit a key to get it to wake up. I've also found
it's possible to freeze the machine with ^C under some circumstances
when writing heavily to pty's. Don't try it without syncing first, and
avoid testing it at all if possible :)
All the above bugs should be fixed in next weeks release, so I'm not
making patches available right now. Additionally, 0.96 has the TIOCCONS
ioctl that allows a pty to get the output intended for the console (so
that you see whan processes write directly to /dev/tty0 etc), as well as
a syslog() system call (syscall nr 103) that reads the messages printed
with printk(). The syslog syscall means you can get the kernel warning
messages to a window under X. Of course, the really bad messages
(notably kernel panics) don't get printed, but hopefully those aren't
that usual.
TIOCCONS was easy to add due to the better vfs routines. Similarly, 0.96
now supports dropping DTR when a serial line is finally closed. Thank
abc for goading me into adding the trivial fix.
In an earlier post I mentioned that 0.96 might have a new floppy-driver:
I just patched it in today, and it seems to work, so that's official.
The new floppy-driver finally allows formatting, and also has
auto-detect floppies (much nicer than under minix: they are quite as
fast as the non-auto versions from my limited testing) as well as
user-defined floppy-types (ie you can define 20-sector formats on the
fly etc..). The patches were courtesy of Werner Almesberger, so send
him a kind thought.
>is libobz.a going to be part of the 0.96 release? it's missing from
>the pre 96 + X patches release, making building any X apps impossible.
Hlu has already added them to the library: the newest version should
have them and some other syscalls ([f]truncate etc). I also think it now
supports multiple shared libraries: practical for X and math. I haven't
had time to try it out myself yet.
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: fsck and inode
Keywords: filesystem,inode
Message-ID: <1992May8.055503.1211@klaava.Helsinki.FI>
Date: 8 May 92 05:55:03 GMT
References: <rickw.705271825@sfu.ca>
Organization: University of Helsinki
Lines: 30
In article <rickw.705271825@sfu.ca> rickw@fraser.sfu.ca (Rick Wong) writes:
>
>I am new to filesystems in unix, so please bear with me.
>
>when I ran the following command
>fsck -m /dev/hda7
>I got these output
>
>inode 266 not cleared
[ etc ]
This is normal under linux: the "-m" flag stands for minix, and means
fsck will do extra checking in the inode like the minix fsck does. The
linux filesystem is almost completely the same as the minix one, but
there are a few very minor differences. The main one is that linux
doesn't clear the i_mode field of an inode that is no longer used, and
minix does.
The result is that if you use minix' fsck, it gives warnings of the
above type after you have used linux for a while. Just so I could get
the same warnings if I wanted, I added the '-m' switch - it's there but
you aren't supposed to use it.
This was mentioned in early readme's, when you actually had to use minix
to set linux up, and people probably used the two systems side by side.
Now I assume most people are running just one or the other, so I haven't
even mentioned it in the readme's any more, as the feature no longer has
any meaning.
Linus
============================
============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Test-image of 0.96 available at banjo
Summary: just the binary
Message-ID: <1992May8.220544.832@klaava.Helsinki.FI>
Date: 8 May 92 22:05:44 GMT
Organization: University of Helsinki
Lines: 37
As 0.96 has some changes in harddisk IO handling (interrupts, timings
etc), I'd like for people that have ever had problems with the harddisk
driver under linux to try out the last test-image of the 0.96 kernel
before the official release - I'd rather not have the same types of
problems that we had with 0.95.
The image (no sources - wait till next week) is available at
banjo.concert.net: pub/Linux/Incoming/testimage.Z, and is just my
current bootimage that I'd like some feedback on.
The changes to the harddisk driver (which is the main reason I want to
make sure this version works) are just:
- interrupts enabled most of the time
- inb_p / outb_p changes
The first one is to lessen interrupt latency, the second one hopefully
helps people who had problems with the driver at high speeds. Both
changes work well for me, but then my machine seems to accept almost
anything... I hope 0.96 will work without any "a" releases.
I'd also be interested to hear if this image removes the problems with
serial lines at high speeds under X, as well as /any/ other problems. I
can still make minor bug-fixes if something turns up, but I'd want
reports by early next week or so (preferably with "testimage" in the
subject line).
The image is compiled with the us keyboard maps, and with the
floppy-device as root. It should be binary compatible with all old
versions, as well as the interim X version, so you just plug in the new
kernel and you're (hopefully) off.
Ignore this post if you don't have time to check out the image this
weekend: the image is only meant as a quick test-release to get some
fast feedback.
Linus
============================
============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Sources (IMPORTANT to managers of LINUX ftp sites)
Message-ID: <1992May11.083344.3440@klaava.Helsinki.FI>
Date: 11 May 92 08:33:44 GMT
References: <1992May9.165404.20041@leland.Stanford.EDU> <7!jkhpq.aclark@netcom.com> <1992May10.202916.26781@news.Hawaii.Edu>
Organization: University of Helsinki
Lines: 24
In article <1992May10.202916.26781@news.Hawaii.Edu> lee@uhunix.uhcc.Hawaii.Edu (Greg Lee) writes:
>
>Since we are so heavily indebted to fsf, it would make sense to think first
>about what is courteous and much later about what we could get away with.
Indeed. I hope people try to follow the /intent/ of the GPL first, and
then start worrying about the legal implications. I don't feel too
strongly about the legalese: it's there just because it's required to
uphold that intent in a court of law, and wouldn't even be needed
otherwise. I'd suggest not reading the GPL searching for loopholes -
but on the other hand not being unnecessarily strict about it either.
Use a bit of common sense in it all (until somebody starts threatening
with legal action: but in that case you have probably not been following
the GPL even in intent).
There are probably quite a few binaries that should be removed from the
linux archives: especially the older ones that needed a bit more porting
than they need now with the better compiler/library, and that might not
have source (I think my original gcc-1.40 and bash-1.05 should probably
be removed: I've had to delete my sources to get X running.. Nobody
uses them any more anyway). It might even result in some general
cleanup of old binaries...
Linus
==============================
==============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: RTS/CTS flow control on serial ports
Message-ID: <1992May11.184925.7185@klaava.Helsinki.FI>
Date: 11 May 92 18:49:25 GMT
References: <1992May10.101454.28203@colorado.edu> <57233@hydra.gatech.EDU>
Organization: University of Helsinki
Lines: 32
In article <57233@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (Jim Burns) writes:
>in article <1992May10.101454.28203@colorado.edu>, drew@romeo.cs.colorado.edu (Drew Eckhardt) says:
>
>> Linux pre-.96 or before does not support hard flow control.
>
>Will it ever?
Well, I did some hacking this Sunday, and the serial driver is now
completely rewritten in C - the file rs_io.s no longer exists. That
also made it easy to implement hangup upon loosing carrier, so that too
is now supported by the 0.96 kernel (which I'll probably send out
tomorrow (Tuesday)).
The rewrite in C is a pretty straightforward translation from the
algorithm I used in assembler, but it should make things very much
easier to change and understand for people not familiar with asm (and
it's easier for me too, I have to admit). Even though flow control
still isn't supported, I'd guess it's now just a matter of a few lines
of C to get it into the kernel, so I expect I'll get patches for it
eventually (or I'll implement it myself when I get bored enough).
The rewrite might mean there are new bugs, and it certainly makes the
interrupts a few instructions slower, but I hope performance won't
suffer noticeably. And adding support for 16550 as well as for
non-standard interrupts should be much easier now, even for people that
aren't heavily into assembly.
The only unnecessary assembler still found in the kernel is the keyboard
driver: I expect I'll clean that up too in a not too distant future.
That one won't be in 0.96, though.
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: filesystems
Message-ID: <1992May11.203853.9747@klaava.Helsinki.FI>
Date: 11 May 92 20:38:53 GMT
References: <IP208.92May11134756@bille.ii.uib.no> <1992May11.141929.25283@klaava.Helsinki.FI> <IP208.92May11212855@puppe.ii.uib.no>
Organization: University of Helsinki
Lines: 36
In article <IP208.92May11212855@puppe.ii.uib.no> magnus@hsr.no writes:
>I may be chewing an old bone here, but is 28 characters in a file name
>really enough..? It's a lot better than what we have now, of course -
>but why not go for the 256 at once?
The reason I chose 30 (or 28) chars is that I don't want to move away
from the fixed-length directory structure for the first "non-minix" vfs
system I write: that way I can avoid some of the troubles, while still
getting a reasonable system. Having a 256-char fixed-length directory
structure is a bit too wasteful even for my taste.
Why fixed-length? It's partly because it's slightly easier (not that
it's that noticeable: I think the vfs routines will have no problem at
all with variable-sized names), but mostly because it can be gotten
almost for free with only minor tweaking of the current minix
vfs-sources. Thus it will serve as an example of having different
filesystems at the same time, while not actually adding very much code
to the kernel.
> Or does what you said imply that I
>can make a few simple changes (additions) in the source and build my
>own filesystem? I still would like 256 ch/filename to be a standard..
Yes, it should be pretty easy to change the sources to add a filesystem
of your own with any filename length (255 chars max due to an arbitrary
limit: I think that will be enough for everybody). It will be a lot
easier when you have some examples, I think.
Also, even if you made this change just on your own system, it isn't
visible on a user level at all, except for the fact that you can create
longer filenames of course. This means that you can run any binaries
you want on the new filesystem, and as long as they have been compiled
with the new gcc-2.1 that supports readdir(), they will work on any
system, including your own specialized fs.
Linus
=============================
=============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: ESDI drive compatibility
Message-ID: <1992May11.141929.25283@klaava.Helsinki.FI>
Date: 11 May 92 14:19:29 GMT
References: <34836@darkstar.ucsc.edu> <1992May10.013723.7373@spuddy.uucp> <IP208.92May11134756@bille.ii.uib.no>
Organization: University of Helsinki
Lines: 31
In article <IP208.92May11134756@bille.ii.uib.no> magnus@hsr.no writes:
>In article <1992May10.013723.7373@spuddy.uucp> sweh@spuddy.uucp (Stephen Harris) writes:
> My next problem is when I plug in my SECOND disk (same size) I'll be forced
> to have 10x64Mb partitions because of the current FS restrictions :-(
>
>Don't worry - the Minix file system is *not* here to stay. I just hope
>it will be easy to transfer files from a minix fs to the new one. Will
>you do 'mount x x [minix|vfs|msdos\..]' in 0.96..? Linus?
0.96 still won't have other filesystems than the old minix one, although
I did get patches to implement longer names and long block-numbers. I'm
pretty certain 0.97 will support 4GB disks and at least 28 character
filenames: the vfs routines finally seem to be pretty logical and I no
longer feel the urge to change a lot of things on that level any more.
And yes, it will be very easy to move around different filesystems: you
can mount them as any normal minix partition, and copy things around
transparently. The only problem will be old binaries that still read
directories directly: those won't be able to handle longer filenames. I
assume that by the time 0.97 comes out, this won't be that much of a
problem any more (assuming new versions at the same rate as before, 0.97
will be out by midsummer or so: I'll continue on linux during the
summer).
The idea behind the vfs routines is that all this can happen without any
major trauma: people can go on using the old filesystem if they wish, or
use several different types at the same time, mounting and umounting
them as they see fit. I haven't done it myself, but I know the routines
work, as others have tried it out.
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 0.96 uploaded
Summary: new release
Message-ID: <1992May12.165112.24234@klaava.Helsinki.FI>
Date: 12 May 92 16:51:12 GMT
Organization: University of Helsinki
Lines: 71
Well, the title says it all: I've sent off 0.96 to banjo.concert.net,
where it can be found in pub/Linux/Linus along with a new bootimage and
a program for formatting floppies under linux (which works only under
0.96).
I've also sent it to tsx-11.mit.edu and I'll send it to nic as soon as
the lines clear up.
General warning about 0.96:
- the scsi code is in the kernel, but I haven't personally tested it,
so who knows... The SCSI code also results in a 4-5 second pause at
bootup with the current bootimage, while it searches for an adapter:
if you find this disturbing, you have to recompile the kernel with the
appropriate changes to config.h.
- The harddisk timings have changed: the testimage got a generally good
review, but it hasn't been tested very much. The changes seem to help
at least some "HD times out" problems, but there might be new bugs..
- The serial code was totally rewritten this weekend, and I haven't
tested it out under any heavier load. I found one bug as late as
today, and there might be others lurking around.
- There have been generally pretty heavy rewrites: it's binary
compatible with the old kernels, but the changes might not all be
correct. Oh, well.
That said, I hope 0.96 will be an improvement on earlier versions, and
most of the old bugs corrected. If the new version still has some
problem - please mail me with a new bugreport. Otherwise I'll just
assume the problem went away: I'm afraid don't have time to go through
old mail searching for any bugs that might still be in there.
Partial list of features:
- automatic floppy detection. Please add the following devices:
mknod /dev/fd0 b 2 0
mknod /dev/fd1 b 2 1
which act as A and B floppies respectively, finding out automatically
what kind of disk there is.
The floppy driver now also contains a timeout, so an empty diskdrive
no longer results in a floppy driver hang.
- serial lines now support dropping DTR on closing, and sending SIGHUP
to the process group that is logged in on a serial line. It's also a
lot easier to change the interrupts etc of the lines.
- unix sockets supported for X, as well as mmap() on /dev/mem etc.
- pty's corrected. Hopefully no more hangs under X due to pty trouble.
- better IO-performance when there are computationally intensive jobs in
the background or on another VC. Partly due to new scheduler
mechanism, partly due to read-ahead on normal files.
- cleaned up vfs layer.
- no more mismatched children
- minor corrections all over the place.
The new release is in fact different enough that there is no use trying
to make context diffs: files have disappeared, others are new, others
have simply changed a lot. Even compared to pre-0.96 there has been
quite a lot of changes.
Linus
==================
==================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Testers wanted... new 0.96 image
Message-ID: <1992May14.132345.12095@klaava.Helsinki.FI>
Date: 14 May 92 13:23:45 GMT
Organization: University of Helsinki
Lines: 15
I've put a new testimage on banjo.concert.net:
pub/Linux/Linus/boot92.05.14.Z
and I hope people that have problems with 0.96 could try it out. I've
mainly tried to remove some races in the serial code, but I hope this
image also corrects the bootup problems experienced by some people.
If you have problems booting the original 0.96, or are seeing more
errors with the new serial lines, please try it out. As with the
earlier testimage, it's no use to me if you can't test it out in a day
or two: by that time I'll probably release 0.96a or a new testimage
depending on the success of this one.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: pcomm95c
Message-ID: <1992May17.112630.28674@klaava.Helsinki.FI>
Date: 17 May 92 11:26:30 GMT
References: <smp.0gdb@myamiga.mixcom.COM> <1992May16.035813.832@uniwa.uwa.edu.au>
Organization: University of Helsinki
Lines: 23
In article <1992May16.035813.832@uniwa.uwa.edu.au> oreillym@tartarus.uwa.edu.au (Michael O'Reilly) writes:
>
>Hmmm. I have the same problem that the original poster had. i.e. haveing
>type a few keys after control-A 0 before the help screen flashes, and
>then it does just that, flashes. Looking deeping, I find that the time
>is actaully spent in the kernel. Somehow (I couldn find it. ) it is
>setting VMIN in the termios structure to be 4. so you have to type 4
>keys before the kernel will return on the read() call.
>
>Fixing this is a matter of finding where the VMIN feild is set. But the
>original program has been hacked so badly, I put it aside for now..
This sounds like a problem I had with some version of kermit: some of
the programs seem to have the c_cc offsets hardcoded into numbers
instead of using VMIN/VEOF etc.. Very bad programming style, and I
think it breaks under linux which doesn't have exactly the same c_cc
offsets as most other unices it seems.
Linux has distinct VEOF (4) and VMIN (6), while for example SunOS seems
to use the same value (4) for both of these. I don't know if the latter
is actually what posix specifies, but I doubt it. Can anybody confirm?
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: minix
Message-ID: <1992May18.111600.26984@klaava.Helsinki.FI>
Date: 18 May 92 11:16:00 GMT
References: <1992May18.101044.26717@athena.mit.edu>
Organization: University of Helsinki
Lines: 50
In article <1992May18.101044.26717@athena.mit.edu> J.Jagger@sheffield-city-poly.ac.uk writes:
>Hello, Linux newbee JJ here. I'm still waiting for a hard disk to
>arrive in the post to install linux, so while I was waiting I thought
>I'd have a quick read of Tanenbaums book 'Operating Systems,
>Design and Implementation.' (This contains the source code to
>MINIX). Two things.
>
>1. The source code for init and the shell are not included (in the
>book). How different are the linux versions from the 'original' MINIX
>versions?
I get the feeling you think linux evolved from minix? This is not true:
linux was written under minix, and while linux superficially resembles
minix386, it's really not that close to minix in any way... The most
minix-like feature in linux is the filesystem: due to practical reasons
I wanted to have the same physical layout of the disk as in minix.
Reading Tanenbaum is good for a general idea of operating systems, but
it's generally not worth it to read the minix specific bits in order to
understand linux (reading the minix source code in order to understand
the genera idea might be worth it). While the filesystem has the same
physical layout, multithreading means locking etc needs to be done
totally differently etc. The kernel proper also uses totally different
design ideals, and the device drivers are also very different (ie they
use interrupts directly instead of waiting for hardware messages etc).
Lastly, minix and linux memory management is fundamentally different:
linux uses paging on a very low level for everything: minix uses a
heap-like memory management strategy, I think.
As to the shell under linux: there are several (although bash is the
only one I use), and the same shells are generally available for minix
as well (not standard PC-minix: it can't run tcsh/bash due to the 64kB
limit). The standard minix shell isn't available for linux (not that
big a loss: the minix shell doesn't do your mental sanity much good):
ash is probably the closest thing.
I don't know about /bin/init: I never looked at the sources under minix,
and I haven't exactly dissected it under linux either.
> [ Lions book ]
>Is this booklet still available ?
>If so does anyone know where I can get a copy of it ?
I doubt you'll find a copy of the Lions book: I think the only way to
get your hands on it would be to find somebody who did the course and
photocopy it off him. I don't think AT&T allows that kind of thing any
more, so it's probably illegal.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: gdb postmortem debugging...
Message-ID: <1992May18.142534.6381@klaava.Helsinki.FI>
Date: 18 May 92 14:25:34 GMT
References: <1992May14.165106.8531@m.cs.uiuc.edu> <1992May18.123608.8795@fwi.uva.nl>
Organization: University of Helsinki
Lines: 15
In article <1992May18.123608.8795@fwi.uva.nl> lankeste@fwi.uva.nl (Branko Lankester) writes:
>
>You can replace do_exit(11) in die() in kernel/traps.c with
>send_sig(SIGSEGV, current, 0), linux versions before 0.96 had
>to use do_exit() because the old trap handlers didn't do signal
>recognition.
Yes, this will fix the problem, but it's not completely safe: if the
error occurs in the kernel, it will probably lock up. Most of the
errors occur in user space, but if syscalls are given bad arguments or
similar you can induce general protection errors in kernel space:
send_sig will not work in that case, while do_exit() always terminates
the process cleanly (but doesn't work for gdb).
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Harddisk problems, new testrelease
Message-ID: <1992May18.165317.11176@klaava.Helsinki.FI>
Date: 18 May 92 16:53:17 GMT
Organization: University of Helsinki
Lines: 23
I've put out the latest test-image on banjo.concert.net in the file
pub/Linux/Linus/boot92.05.18.Z: it should hopefully correct the harddisk
problems some people have had with plain 0.96. I'll make it official by
calling it 0.96a if there are no more problems (and make source
available as well. Later this week).
If you had fs corruption problems or similar with 0.96, try out the new
version: unless I get feedback on it, I can't try to correct any
remaining hardware-related bugs.
It seems the harddisk interrupts have to run to completion with all
other interrupts disabled: I haven't found out exactly where the problem
is, but that's how it looks right now. Thus interrupt latency went up
again :(. It's still better than 0.95, I hope.
The above testimage (and the upcoming 0.96a release) contains the kill
fix (and the same serial fixes as in the last testimage), and uses the
rewritten keyboard handler by Johan Myreen (essentially the same driver,
but rewritten in C).
Linus
PS. boot92.05.18.Z on saatavilla my|s klaavassa: /usr/tmp/linux
===========================
===========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: linux as only bootable partition
Keywords: linux, boot, shoelace
Message-ID: <1992May21.063838.3334@klaava.Helsinki.FI>
Date: 21 May 92 06:38:38 GMT
References: <1992May21.053756.13081@cs.ubc.ca>
Organization: University of Helsinki
Lines: 16
In article <1992May21.053756.13081@cs.ubc.ca> edmonds@cs.ubc.ca (Brian Edmonds) writes:
[ just answering the PS - I don't have DOS, but I still boot from floppy
just because I want to have several different kernel images... ]
>
>PS: when is 16550 support expected? I specificly ordered serial
>ports with these, as the FIFO seems an especially elegant solution to
>too many interrupts at high data rates.
I'd love to support a 16550, but I don't have any data on it (and no
chip). The optimal solution would be that somebody else writes the
changes to the serial driver, but I can certainly try to do it blind if
I could get docs. So if somebody has good technical dosumentation on
the 16550 in machine-readable format, please mail it to me: I won't
promise anything, but I might get it to work.
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 0.96a out today/tomorrow
Message-ID: <1992May21.121955.1485@klaava.Helsinki.FI>
Date: 21 May 92 12:19:55 GMT
Organization: University of Helsinki
Lines: 49
The subject say it all: I haven't heard any bad results (except somewhat
worse performance on the serial lines) from the testimage testers, so
I'll make 0.96a available tonight (Finnish time: EST) or tomorrow.
tsx-11, nic and banjo will be the sites I'll upload it to.
0.96a doesn't have any major new features: I just tried to correct known
bugs and get a stable version out the door. I hope 0.96 won't need any
more interim releases, but we'll see.
0.96a has gone back to non-interruptible hd-interrupts, and as long as
I'm not sure about the reason for the need of this, it's going to stay
that way. I hope this new version will run on all drives that have been
supported in the past, and the only known remaining problem is the Kalok
drives which have spurious interrupts. That's definitely a hardware
problem, and Branko Lankaster has patches that fake away these..
0.96a should also correct most of the serial line problems, and the
keyboard driver is now in C - I expect somebody will change it to allow
run-time keyboard changing. Additionally, there are various minor fixes
in various places:
- the kill fix by tytso that allows any process to wake up a stopped
process as long as it's in the same session.
- chown fix by card and me. Users can chgrp files they own to any group
they belong to etc - _POSIX_CHOWN_RESTRICTED should now be implemented
correctly. Also, chown() on a symlink now actually chown's the symlink
and not the file it points to (but GNU fileutils don't seem to want to
chown symlinks anyway - or maybe I have an older version)
- SIGSEGV fix by lankaster (?) which allows for better debugging after
protection faults. Most such errors are now trappable in gdb
(although some circumstances can still result in the process exiting
at once: out-of-memory errors etc)
I have also changed the memory manager to check for illegal memory
references (ie using the area between brk and stack), so debugging bad
pointer references should be much easier. This fix will hopefully also
trap the uncompress problem with bad files, but I haven't tried it out.
Programs can still call brk() with any value, so it doesn't mean that
you can't use up all available memory, but at least this should fix
/bad/ memory references. My limited tests with gdb seems to indicate it
all works nicely.
Core files are still not generated (I haven't got the slightest idea
what format they should have), so debugging isn't perfect yet, but it
should certainly be much easier.
Linus
===========================
===========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: VFS - Where can I read about it?
Message-ID: <1992May22.050933.22701@klaava.Helsinki.FI>
Date: 22 May 92 05:09:33 GMT
References: <BoMFDB.6wD@ais.org>
Organization: University of Helsinki
Lines: 49
In article <BoMFDB.6wD@ais.org> lcd@ais.org (Leon Dent) writes:
>I read comp.os.linux, but don't (can't) yet run it. The VFS concept
>interests me, but I don't know what books or papers explain it.
>Pointers anyone?
As with the rest of the kernel internals, linux VFS doesn't exactly look
like anything else: the ideas are the same as in SunOS etc, but the
implementation is linux-specific (the first alpha-release used similar
macros as SunOS I think, but after my rewrites...)
So the only place to learn about linux VFS is the source code. It's not
really that bad: it's pretty simple. The different routines are
selected by following pointers to structures containg function-pointers.
For example if you want to find out which inode the name "/usr" points
to, you can use something like this (simplified, but you get the idea):
...
dir = current->root;
if (!dir->i_ops || !dir->i_ops->lookup)
return -ENOTDIR;
inode = dir->i_ops->lookup(dir,"usr");
...
Similarly, if you wanted to create the directory of "src/linux" relative
to the current pwd, you'd use something like this:
dir = current->pwd;
if (!dir....
inode = dir->i_ops->lookup(dir,"src");
if (!inode || !inode->i_ops || !inode->i_ops->mkdir)
return -ENOENT;
return inode->i_ops->mkdir(inode,"linux");
(when I use a string in the above, the real routines actually use a
pointer+length combination instead of the normal C strings. This means
there is no need to copy names around: we use the name the user supplied
directly, and the VFS routines parse away the slashes.. And as the
pointers are relative to the %fs segment, we can choose user/kernel
space strings just by changing the segment)
So the VFS layer just translates the unix system calls to these kinds of
indirect calls, keeping track of mount points/root/pwd etc. Thus the fs
is effectively in two separate pieces: the VFS which parses complete
filenames, and the filesystem-specific parts which just work on one part
at a time. The VFS doesn't care about the disk layout, and the
fs-specific parts don't have to know anything about mount-points/current
root/pwd etc idiosyncracies.
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: VFS - Where can I read about it?
Message-ID: <1992May22.201941.13737@klaava.Helsinki.FI>
Date: 22 May 92 20:19:41 GMT
References: <BoMFDB.6wD@ais.org> <1992May22.050933.22701@klaava.Helsinki.FI> <JES.92May22124113@mbio.med.upenn.edu>
Organization: University of Helsinki
Lines: 29
In article <JES.92May22124113@mbio.med.upenn.edu> jes@mbio.med.upenn.edu (Joe Smith) writes:
>
>What happens with mkfs & fsck? Can these be written using standard
>Unix system calls (through the VFS, and thus are indifferent to fs
>changes), or will we need a separate executable (or switch) for each
>fs? Are we still without source for fsck and if so, will the old one
>work with a 30-char-filename fs? How about mount?
mkfs/fsck will have to be written especially for each filesystem: these
are purely user-level programs which operate directly on the block
device. mkfs is usually very simple to write: the only thing needed is
to set up an empty filesystem so that the kernel can then start
operating on it and fill it with data, but fsck is a very complicated
program, and getting it right is not easy (the current linux fsck is not
very good, and does only a half-hearted job which isn't good enough in
many situations)
As to mount(), this is a kernel primitive, and is part of the filesystem
drivers. Mount is given a extra parameter that indicates which type of
filesystem to mount (the name of the filesystem type), and then
"bootstraps" the filesystem information by filling in the appropriate
inode operations for the root inode of the new filesystem etc.
So to mount a DOS filesystem (if/when it is finally implemented), you'd
use something like "mount /dev/hdb3 /local DOS". The current mount just
gives a NULL for the filesystem name, which the kernel takes to be the
default minix filesystem.
Linus
===========================
===========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 0.96a available
Message-ID: <1992May22.210159.14611@klaava.Helsinki.FI>
Date: 22 May 92 21:01:59 GMT
Organization: University of Helsinki
Lines: 36
Oh, well, no use in delaying it any more, so I sent out my latest
release to nic.funet.fi, tsx-11.mit.edu and banjo.concert.net. They
should show up in the next couple of days (they are already visible on
banjo: /pub/Linux/Linus). I hope all the bugs got fixed, but I did
something potentially stupid:
I had expected that lankaster wouldn't get his hd-speedup patches ready
for 0.96a, and I was resigned to the same hd-performance as with all
older releases. But when I saw them on the newsgroup today I thought
I'd try them out just in case, as I could always use my backup-version
if they backfired...
The point here is that the patch ended up in 0.96a after some minor
edits by me (one benign bug and some editing due to changed files). So
now hd-performance is much better on most operations. I just hope it
doesn't result in yet another release just to fix new bugs (but I doubt
it: the patches were really minor and clean - no ugly hacks needed I'm
happy to say). Branko already posted benchmarks, and I can only confirm
that it's indeed snappier, especially on writes. syncing is no longer a
pain even after heavy writing.
Other than the hd-performance, there are no new features I haven't
already mentioned in other posts. Bug-fixes, rewrites in C, better
debugging. I haven't made the cdiffs yet, so right now the new release
is only available as complete source and as a binary, but I'll try to
get patches done tonight. Possibly tomorrow. The patches will be
against the original 0.96, and shouldn't be too big.
Linus
PS. No need for more 16550 info: even if somebody doesn't implement it
for the next release, I think I can get it going. Doesn't seem too
hard. I'll also start to look into core-files. Eventually. Promise.
PPS. Ja 0.96a on taas saatavilla klaavasta /usr/tmp/linux'ssa
yliopistolla kirjoilla oleville.
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Unable to boot 0.96a
Message-ID: <1992May23.195321.4721@klaava.Helsinki.FI>
Date: 23 May 92 19:53:21 GMT
References: <2A1E9A99.25394@ics.uci.edu>
Organization: University of Helsinki
Lines: 22
Oh boy. I saw the subject line and thought "here it starts again...".
Happily, this is a problem that should be easily solveable..
In article <2A1E9A99.25394@ics.uci.edu> bvickers@bonnie.ics.uci.edu (Brett J. Vickers) writes:
> The "Loading..." came up, and after
>several more "."s, it went into an endless (debugging?) loop of
>some sort, putting the following on my screen over and over again:
>
>@X: 1009
>AX: 0212
>BX: 7E00
>CX: 0901
>DX: 0000
This just indicates that the floppy seems to be bad, or some similar
problem. The bootup sequence is pretty unstable, and if there are any
problems at all reading in the system, it usually goes into a loop
printing out the error-messages.
Make sure the floppy is high-density, reformat, and try again.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Patches...
Message-ID: <1992May24.104310.16221@klaava.Helsinki.FI>
Date: 24 May 92 10:43:10 GMT
Organization: University of Helsinki
Lines: 28
I finally got around to doing the cdiffs against 0.96, and uploaded them
to the usual ftp-archives (nic,tsx and banjo). The patches are actually
about 35kB compressed, but they aren't as big as that sounds: it's
mainly due to the serial line changes and the fact that the keyboard
driver was changed to C. I don't know if somebody is actually going to
get the patches instead of the whole distribution, but at least it's
available if somebody does want it.
If you decide to get 0.96a by patching from 0.96, get the patch-file
(diff0.96-0.96a.Z), apply it, and remove the old keyboard.S driver: it
is no longer needed. You should also do a "make dep" to get the
dependencies up-to-date: I removed those from the cdiffs.
I am also going to upload the first set of patches against 0.96a later
today. The reason is that the faster harddisk driver had problems with
error situations, which I think I've fixed now. The patches also
correct the VC restoration with X11 after exiting (but see later). The
bugs aren't big enough to require a new version (so far I haven't had a
single bug-report on 0.96a: does it really work that well or are people
afraid to try it out?), so I'm just making the cdiffs available.
As to X: if you are using 0.1 it I'd suggest getting the new version.
It corrects the text-mode restoring bug, and with 0.96a with patch 1
applied I haven't seen any problems at all. xterm now handles resizing
correctly, and has shrunk considerably due to the multiple shared
libraries (from 570kB to 115kB).
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: linux-0.96a.patch1
Message-ID: <1992May24.114643.17027@klaava.Helsinki.FI>
Date: 24 May 92 11:46:43 GMT
Organization: University of Helsinki
Lines: 257
Here is the patch to 0.96a that corrects the harddisk error bug, dup2()
and X11 text-mode restoration. Thanks to Rick Sladkey for finding the
dup2() bug.
This patch has also been sent to the ftp-archives.
Linus
----------
*** 0.96a/linux/fs/fcntl.c Fri Apr 24 18:36:09 1992
--- linux/fs/fcntl.c Sat May 23 23:24:24 1992
***************
*** 37,42 ****
--- 37,44 ----
int sys_dup2(unsigned int oldfd, unsigned int newfd)
{
+ if (oldfd >= NR_OPEN || !current->filp[oldfd])
+ return -EBADF;
if (newfd == oldfd)
return newfd;
sys_close(newfd);
*** 0.96a/linux/kernel/chr_drv/console.c Thu May 14 17:40:19 1992
--- linux/kernel/chr_drv/console.c Sun May 24 04:03:01 1992
***************
*** 56,64 ****
INIT_C_CC \
}
- static void blank_screen(void);
- static void unblank_screen(void);
-
/*
* These are set up by the setup-routine at boot-time:
*/
--- 56,61 ----
***************
*** 223,229 ****
{
if (video_type != VIDEO_TYPE_EGAC && video_type != VIDEO_TYPE_EGAM)
return;
! if (currcons != fg_console)
return;
cli();
outb_p(12, video_port_reg);
--- 220,226 ----
{
if (video_type != VIDEO_TYPE_EGAC && video_type != VIDEO_TYPE_EGAM)
return;
! if (currcons != fg_console || vt_cons[currcons].vt_mode == KD_GRAPHICS)
return;
cli();
outb_p(12, video_port_reg);
***************
*** 584,593 ****
printk("con_write: illegal tty\n\r");
return;
}
- if (vt_cons[currcons].vt_mode == KD_GRAPHICS) {
- flush(tty->write_q);
- return; /* no output in graphics mode */
- }
while (!tty->stopped && (c = GETCH(tty->write_q)) >= 0) {
if (c == 24 || c == 26)
state = ESnormal;
--- 581,586 ----
***************
*** 834,841 ****
state = ESnormal;
}
}
- set_cursor(currcons);
timer_active &= ~(1<<BLANK_TIMER);
if (currcons == fg_console)
if (console_blanked) {
timer_table[BLANK_TIMER].expires = 0;
--- 827,836 ----
state = ESnormal;
}
}
timer_active &= ~(1<<BLANK_TIMER);
+ if (vt_cons[currcons].vt_mode == KD_GRAPHICS)
+ return;
+ set_cursor(currcons);
if (currcons == fg_console)
if (console_blanked) {
timer_table[BLANK_TIMER].expires = 0;
***************
*** 1129,1136 ****
if (currcons<0 || currcons>=NR_CONSOLES)
currcons = 0;
- if (vt_cons[currcons].vt_mode == KD_GRAPHICS)
- return; /* no output in graphics mode */
while (c = *(b++)) {
if (c == 10) {
cr(currcons);
--- 1124,1129 ----
*** 0.96a/linux/kernel/chr_drv/vt.c Wed May 6 21:00:29 1992
--- linux/kernel/chr_drv/vt.c Sun May 24 03:50:43 1992
***************
*** 15,20 ****
--- 15,21 ----
#include <linux/sched.h>
#include <linux/tty.h>
+ #include <linux/timer.h>
#include <linux/kernel.h>
#include "vt_kern.h"
***************
*** 121,127 ****
default:
return -EINVAL;
}
! vt_cons[console].vt_mode = arg;
return 0;
case KDGETMODE:
verify_area((void *) arg, sizeof(unsigned long));
--- 122,138 ----
default:
return -EINVAL;
}
! if (vt_cons[console].vt_mode == (unsigned char) arg)
! return 0;
! vt_cons[console].vt_mode = (unsigned char) arg;
! if (console != fg_console)
! return 0;
! if (arg == KD_TEXT)
! unblank_screen();
! else {
! timer_active &= 1<<BLANK_TIMER;
! blank_screen();
! }
return 0;
case KDGETMODE:
verify_area((void *) arg, sizeof(unsigned long));
*** 0.96a/linux/kernel/blk_drv/hd.c Fri May 22 20:56:49 1992
--- linux/kernel/blk_drv/hd.c Sat May 23 17:03:41 1992
***************
*** 424,430 ****
return;
if (++CURRENT->errors >= MAX_ERRORS)
if (CURRENT->bh && CURRENT->nr_sectors > 2) {
! CURRENT->nr_sectors &= ~1;
next_buffer(0);
} else
end_request(0);
--- 424,435 ----
return;
if (++CURRENT->errors >= MAX_ERRORS)
if (CURRENT->bh && CURRENT->nr_sectors > 2) {
! CURRENT->nr_sectors--;
! CURRENT->sector++;
! if (CURRENT->nr_sectors & 1) {
! CURRENT->nr_sectors--;
! CURRENT->sector++;
! }
next_buffer(0);
} else
end_request(0);
***************
*** 530,536 ****
cli();
if (++CURRENT->errors >= MAX_ERRORS)
if (CURRENT->bh && CURRENT->nr_sectors > 2) {
! CURRENT->nr_sectors &= ~1;
next_buffer(0);
} else
end_request(0);
--- 535,546 ----
cli();
if (++CURRENT->errors >= MAX_ERRORS)
if (CURRENT->bh && CURRENT->nr_sectors > 2) {
! CURRENT->nr_sectors--;
! CURRENT->sector++;
! if (CURRENT->nr_sectors & 1) {
! CURRENT->nr_sectors--;
! CURRENT->sector++;
! }
next_buffer(0);
} else
end_request(0);
*** 0.96a/linux/kernel/blk_drv/blk.h Fri May 22 20:56:49 1992
--- linux/kernel/blk_drv/blk.h Sat May 23 17:00:10 1992
***************
*** 149,174 ****
wake_up(&bh->b_wait);
}
- extern inline void next_buffer(int uptodate)
- {
- struct buffer_head *tmp;
-
- CURRENT->bh->b_uptodate = uptodate;
- unlock_buffer(CURRENT->bh);
- if (!uptodate) {
- printk(DEVICE_NAME " I/O error\n\r");
- printk("dev %04x, block %d\n\r",CURRENT->dev,
- CURRENT->bh->b_blocknr);
- }
- tmp = CURRENT->bh;
- CURRENT->bh = CURRENT->bh->b_reqnext;
- tmp->b_reqnext = NULL;
- if (!CURRENT->bh)
- panic("next_buffer: request buffer list destroyed\r\n");
- CURRENT->buffer = CURRENT->bh->b_data;
- CURRENT->errors = 0;
- }
-
extern inline void end_request(int uptodate)
{
struct request * tmp;
--- 149,154 ----
***************
*** 188,193 ****
--- 168,195 ----
wake_up(&tmp->waiting);
tmp->dev = -1;
wake_up(&wait_for_request);
+ }
+
+ extern inline void next_buffer(int uptodate)
+ {
+ struct buffer_head *tmp;
+
+ tmp = CURRENT->bh;
+ CURRENT->bh = tmp->b_reqnext;
+ tmp->b_reqnext = NULL;
+ tmp->b_uptodate = uptodate;
+ unlock_buffer(tmp);
+ if (!uptodate) {
+ printk(DEVICE_NAME " I/O error\n\r");
+ printk("dev %04x, block %d\n\r",tmp->b_dev, tmp->b_blocknr);
+ }
+ if (!CURRENT->bh) {
+ printk("next_buffer: request buffer list destroyed\r\n");
+ end_request(0);
+ return;
+ }
+ CURRENT->buffer = CURRENT->bh->b_data;
+ CURRENT->errors = 0;
}
#ifdef DEVICE_INTR
*** 0.96a/linux/include/linux/tty.h Wed May 20 12:15:42 1992
--- linux/include/linux/tty.h Sun May 24 03:46:56 1992
***************
*** 195,200 ****
--- 195,202 ----
void copy_to_cooked(struct tty_struct * tty);
void update_screen(int new_console);
+ void blank_screen(void);
+ void unblank_screen(void);
int kill_pg(int pgrp, int sig, int priv);
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux X question
Message-ID: <1992May25.093156.8405@klaava.Helsinki.FI>
Date: 25 May 92 09:31:56 GMT
References: <13489@umd5.umd.edu>
Organization: University of Helsinki
Lines: 37
In article <13489@umd5.umd.edu> colbert@astro.umd.edu (Edward J.M. Colbert) writes:
>I would like to occasionally open an xterm and log in as root --
>without having to shutdown X11 completely. Normally, one could
>login as root, but for some reason, when I have X loaded, the only
>user I can 'login' as is the one I started X from. What's the
>solution?
Add the pty devices to your /etc/securetty (or whatever), or root won't
be able to log in on a xterm. Also, make login setuid. I /think/ that
should do it, but I haven't tried it myself..
As an aside to persons that are having problems with xterm or anything
else that uses pty's: make sure your /dev has the correct pty entries.
They were wrong on the 0.12 root-disk, I think, and some people have had
problems with it. The correct entries are:
ptyp0 c 4 128
ptyp1 c 4 129
...
ttyp0 c 4 192
ttyp1 c 4 193
...
(also note that the standard kernel has only 4 pty's compiled into it,
and if you want more you have to recompile the kernel. Getting 0.96(a)
is a good idea: there were bugs in the pty-code in earlier versions that
caused the kernel to hang under certain circumstances)
>Also, when X shuts down, I lose my text screen and all of my virtual
>consoles. What's going on here?
This is an X11 bug and has been corrected in the new version - if you
aren't on the X11 mailing-list you won't have seen the message. Shame
on you.
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: X386 dies prematurely
Keywords: linux X386
Message-ID: <1992May25.100710.9861@klaava.Helsinki.FI>
Date: 25 May 92 10:07:10 GMT
References: <1992May25.040712.17267@infonode.ingr.com>
Organization: University of Helsinki
Lines: 26
In article <1992May25.040712.17267@infonode.ingr.com> pitaka@infonode.ingr.com (Anucha Pitak) writes:
>I got the following message when I ran startx,
>
>---------------------------------------------------------------
>X386 Version 1.2 / X Windows System [linux version]
>(protocol Version 11, revision 0, vendor release 5000)
>
>
>giving up
>xinit: Invalid argument (errno 22): unable to connect to X server
>xinit: No such process (errno 3) : server error.
>---------------------------------------------------------------
>
>I have 386-25 (DTK mother board), paradise WD90C00, and microsoft
>compatible serial mouse.
With these kinds of problems it's usually a good idea to redirect stderr
to a file: otherwise some of the error-messages might get lost if they
are printed while linux is in graphics mode (this is corrected by the
patch1 to 0.96a). X386 usually tries to tell you the reason why it's
giving up: it might be due to a missing Xconfig or just bad
configuration (ie X doesn't find the fonts where it expected them etc).
Try to do a "startx 2&> tmp" and "cat tmp" to see if you get some more
information.
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: porting screen3.2: possible kernel/library bugs?
Message-ID: <1992May25.092323.8195@klaava.Helsinki.FI>
Date: 25 May 92 09:23:23 GMT
References: <58717@hydra.gatech.EDU> <58836@hydra.gatech.EDU>
Organization: University of Helsinki
Lines: 65
In article <58836@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (BURNS) writes:
>
>Before I start a flame war on vc's vs. screen(1) here like we just had in
>comp.unix.bsd, I'm only interested in the learning experience of what port-
>ing a moderately featureful package to linux entails, not using it (except
>on serial port logins, of course). Vc's are fine for me.
>
>Background: screen(1) forks into two processes - screen, & SCREEN.
>
>1) Compiles crawl if there is a SCREEN running anywhere, even on another
>vc. Crawl means 2-3x slower. Kind of surprising, since top(1) shows SCREEN
>spends most of its time in do_select. It's real easy to chew up memory too.
>Screen(1) takes up 200-300k, plus ~200k for each bash (tho' that may be
>comparable to bash on a vc). I would have expected the COW paging to be
>more efficient than that. Makes compiling *impossible* after a while
>(signal 11).
>
>Q1) are select() and COW working well?
COW - yes, select() don't know. You don't mention which kernel you are
running, but select() shouldn't be a problem on 0.96. X uses select()
all the time, and I certainly don't see the above kinds of problems.
I think both your problems are due to memory limitations: gcc certainly
starts to crawl when memory gets tight, and linux starts discarding
clean (ie code) pages. Note that linux doesn't give the signal 11 at
once when memory is down: first it tries to run the processes by
discarding all pages that aren't needed and can be re-demand-loaded in.
COW and demand-loading works very well indeed: I routinely have 2MB
shared pages when running X or similar. But if you are running on a 2MB
or 4MB machine, and are tight for memory, the clean pages are the first
thing that linux starts re-using for other things: and as the clean
pages are also what can be shared among processes, sharing is no longer
as efficient.
The above just means that with 4MB of ram, you have 2.5MB free for
processes. Assuming you run gcc, that isn't too much, and linux will
try to keep only dirty pages in memory. In fact enabling swapping can
/improve/ performance in this kind of circumstance: that gives linux a
chance to swap out dirty pages, and give more room to code-pages that
otherwise would have to be on disk.
>Q2) do named pipes have an upper limit on the amount of data that can be
>written (2092 bytes above), and is this configurable? (I don't believe the
>pipe is being opened w/O_NONBLOCK, but I haven't read the code for the
>reader. The writer did not.)
Named pipes don't exist in the normal linux kernel, so it's no wonder
you can't do anything with them. You can create a special file that
looks like a named pipe (the mknod() system call works ok), but there
are no routines to actually handle IO on them. If you try, you will get
an EINVAL error code, and the kernel will print out a small message
telling you why (ie "(read): inode->i_mode = 010600" or similar)
>3) if I understand the man page correctly, you should be able to use
>setreuid(2) to swap your real & effective uids all day long. The test
>program below shows this fails after the FIRST setreuid(2).
>
>Q3) Why?
I haven't got the setreuid manual, and it seems there is a bug in the
kernel. I'll have to check it out eventually.
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.96 and 0.96a comments (and a bug report)
Keywords: kernel bug 0.96 0.96a
Message-ID: <1992May25.153807.17572@klaava.Helsinki.FI>
Date: 25 May 92 15:38:07 GMT
References: <mper.706768401@uipsuxb> <1992May25.151353.4083@cbnewsj.cb.att.com>
Organization: University of Helsinki
Lines: 14
In article <1992May25.151353.4083@cbnewsj.cb.att.com> nhc@cbnewsj.cb.att.com (n.h.chandler) writes:
>
>Same here, the "bogus do_no_page" messages are annoying. I
>wonder, are they benign or is something nasty happening here?
The "bogus do_no_page" message seems to be related to older 386-chips,
and right now I'm assuming it's due to a bug in early 386's. Anyway,
the 0.96 version seems to handle them cleanly, so you should be able to
just uncomment the offending printk() in the sources, and recompile.
I left the message in, as I wasn't sure it is 100% ok even in the new
version, and I'd rather have too many debugging messages than too few.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: problems with ps, pcomm95c+1 and more...
Message-ID: <1992May26.055800.4646@klaava.Helsinki.FI>
Date: 26 May 92 05:58:00 GMT
References: <1992May24.195213.1118@colorado.edu> <N04BLB2w164w@starcom.UUCP>
Organization: University of Helsinki
Lines: 20
In article <N04BLB2w164w@starcom.UUCP> mattm@starcom.UUCP (Matt Mosley) writes:
>> [ ps database ]
>> This must be built from the unstripped kernel binary.
>
>Yes, but *how* do you build it?
"ps U XXXX" works for most kernel releases (where XXXX is the name of
the unstripped system binary), but with some kernel releases (including
the next one) you also have to recompile ps as the kernel structures
change. If 'ps U' doesn't work, and you have updated to a new version,
this can be the problem: the task-structure has probably changed betweem
versions.
Note that the next version of linux will use itimers instead of the old
alarm interface, and thus the ps sources actually have to be edited a
bit, as the alarm structure no longer exists. (No other binaries break,
and itimers means you can run xneko...). [ itimers implemented by
Darren Senn ]
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: What files to grab ?
Message-ID: <1992May27.113053.4804@klaava.Helsinki.FI>
Date: 27 May 92 11:30:53 GMT
References: <1992May27.072415.23819@ccds3.ntu.edu.tw>
Organization: University of Helsinki
Lines: 47
In article <1992May27.072415.23819@ccds3.ntu.edu.tw> kcsu@ccds2.cc.ntu.edu.tw (Kuo-Chun Su) writes:
>
> I am new to Linux. When I connect to tsx-11, I find a lot of files
> which I don't quite know. Would anyone tell me what files are needed if
> I want to install Linux, including Linux's sources and executables, X11,
> GCC, and every other things required to do X programming ?
X and gcc are in a constant flux right now: before getting the binaries
it's a good idea to join the X11 and gcc mailing-lists. The newest
version of gcc is a pre-release of gcc-2.2, and the libraries change
almost daily if you really want to keep up. It's a bit of a bother, but
the result of it all is that most of the library bugs seem to have been
fixed.
Other than the compiler and X11, the easiest way to install linux right
now is to get the mcc-interim version, and then upgrading to the newest
kernel image. The mcc-interim version had some problems with the login
binary, but I think they got fixed. The mcc distribution contains most
of the basic unix utilities.
> Another question. Could anyone describe the pros and cons of Linux
> and Coherent 386 for me ?
Well, coh386 isn't available for a couple of weeks yet, but this is how
I've understood all the hype:
Linux pros:
- virtual memory, page sharing. VERY BIG pro.
- free, full source.
- X11 and a lot of other good software already ported.
- good support from hackers
Coh386 pros:
- manual. Easier installation. BIG pro.
- runs standard text-mode 386-unix and coh286 binaries.
- support from MWC
> Also, if Linux more reliable and stable than
> BSD386 ?
Haven't tested 386BSD, but I assume it will be pretty good in a month or
two, and it's probably quite useable already. If you want NFS and full
networking, it's the way to go. Comments, anyone?
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: longer filenames dilemma
Message-ID: <1992May27.190815.15318@klaava.Helsinki.FI>
Date: 27 May 92 19:08:15 GMT
References: <SCHMID.92May27105513@fb3-s2.fb3-s7.math.TU-Berlin.DE> <1992May27.102933@tioga.ucsc.edu>
Organization: University of Helsinki
Lines: 37
In article <1992May27.102933@tioga.ucsc.edu> sinster@scintilla.capitola.ca.us writes:
>In article <SCHMID.92May27105513@fb3-s2.fb3-s7.math.TU-Berlin.DE>, schmid@fb3-s7.math.TU-Berlin.DE (Gregor Schmid) writes:
>> Changing this value to s.th. else (preferred 2^n - 2) and recompiling
>> should give you a kernel that handles longer filenames (right Linus ?).
>> The problem: You have to rebuild mkfs with the new header and remake
>> your file system. That's inconvenient but unavoidable.
>
>Here's the problem bothering me: why does the filesystem have to be rebuilt?
>This implies that the full MAX_NAME bytes of space are allocated on the
>filesystem for file names. This is very bad. BSD, for instance, uses
>a linked-list of filename/inode pairs to represent directories on disk.
>This is read into memory and converted to an array of char * for efficiencies'
>sake.
I'll try to clarify once more about the linux filesystem implementation:
Nothing in the linux vfs depends on any particular name-length or on the
fact that names are fixed-length: it's just the minix filesystem that
doesn't support anything else. You /can/ just change the current
routines to use longer names, but this isn't a good idea: as Gregor
Schmid noted, this means the old filesystem no longer works.
Adding a second filesystem type that doesn't have the minix limitations
isn't that difficult: Remy Card did it even in 0.95 as he needed longer
filenames in order to compile mach under linux. In 0.96 vfs is a bit
better suppoted, so it should be even easier as long as you know what
you are doing. Card is now working on a better filesystem (his first
one was essentially the minix one, but using 30-character names, I
believe), and I hope it will make it into 0.97.
When you add a new filesystem by way of the vfs routines, it means that
old filesystems are still supported - no need to re-mkfs everything, and
copying between filesystems is totally transparent, as long as the
underlying filesystem doesn't have some requirements (like 8+3 filenames
or similar).
Linus
=============================
=============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux swapping
Message-ID: <1992May29.171214.8939@klaava.Helsinki.FI>
Date: 29 May 92 17:12:14 GMT
References: <9spkbss6@cck.coventry.ac.uk> <235kl7h.james@netcom.com>
Organization: University of Helsinki
Lines: 65
In article <235kl7h.james@netcom.com> james@netcom.com (James L. Paul) writes:
>In article <9spkbss6@cck.coventry.ac.uk> csg203@cch.coventry.ac.uk (Bluebeard) writes:
>>
>>I have 2megs of memory and 4megs of swap.
>>
>>Does this give me a total of 6megs or only 4 ?
It gives you 6MB of memory (but remember that 1MB is used by the kernel).
>>A unix expert, told me that the actual memory maps onto the swap, so only the
>>swap space above the system memory is available.
>>Is this true on linux ?
This is true on some unixes (I think SunOS does it that way), but linux
uses swap as /additional/ memory. (well, one page of the swap-space is
used for the good-page bitmap and the swapspace signature).
>>I'm considering upgrading to 4meg of RAM, but as I've only got a 40meg
>>partition, I wasn't intending to increase the swap space.
I'd sertainly suggest upgrading to 4MB ram and 4MB swap: you'll notice
everything is much snappier, especially compiles.
>As another Linux beginner, I'd like to hear the answer to this too.
>My question is, does Linux swap or page? The use of the term swap is
>prevalent in Linux (ie, swap space, swapon) but I also saw descriptions
>of swap space given in pages?
Linux does only paging, no swapping in the meaning "write out one whole
process to disk".
The reason I have called it swapping is that linux used paging for
memory management on a low level from the first version (0.01), but
didn't page to disk at all until version 0.12 (well, there was a
testversion out for 0.11, but 0.12 was the first version that did it
"officially"). So when paging to disk came along, I called it swapping
to distinguish it from the memory management paging linux has done all
along.
> And is demand paging different from paging? How?
Demand-paging is really "demand-loading of executables" and is totally
independent of the page-swapping algorithms, although they obviously
have similarities. When linux starts up a process, no actual code space
is loaded: I let the page exceptions load in the executable as needed.
Thus linux demand-loads the code and initialized data it needs.
Demand-loading has a couple of very good points: (1) it simplifies the
exec system call, (2) it means page-sharing between processes that have
executed the same file is easy to implement, and (3) it cuts down on the
amount of memory required. When linux runs out of real memory, it
starts to look for pages it can swap out: but if it notices that the
page is clean, it just forgets about it, and demand-loads it when it's
needed again. That means the swap-file isn't needed as much, especially
when running big binaries like gcc, where the code-pages can be
demand-loaded as you wish.
Point (3) means that even without any swapspace, you can usually run
slightly larger programs than your memory setup would actually permit.
I've noticed this while running X and doing a kernel compile + something
else when I've forgotten to turn on swapping: free reports 0 pages
available, but things still work, although performance is of course
slightly down..
Linus
==============================
==============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux swapping
Message-ID: <1992Jun1.181745.15703@klaava.Helsinki.FI>
Date: 1 Jun 92 18:17:45 GMT
References: <235kl7h.james@netcom.com> <1992May29.171214.8939@klaava.Helsinki.FI> <1992Jun1.134501.3210@bwdls61.bnr.ca>
Organization: University of Helsinki
Lines: 40
In article <1992Jun1.134501.3210@bwdls61.bnr.ca> mleech@bnr.ca (Marcus Leech) writes:
>In article <1992May29.171214.8939@klaava.Helsinki.FI>, torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>|> When linux runs out of real memory, it
>|> starts to look for pages it can swap out: but if it notices that the
>|> page is clean, it just forgets about it, and demand-loads it when it's
>|> needed again. That means the swap-file isn't needed as much, especially
>|> when running big binaries like gcc, where the code-pages can be
>|> demand-loaded as you wish.
>
>A problem with this scheme is that your page-fault latency is limited by the
> efficiency of the filesystem. Other OS/UNIX implementations that support
> "demand load" executables copy demand-loaded pages into the paging
> area after they've been faulted in. Once that's happened, subsequent
> faults for the same page come out of the paging area. Paging-area
> I/O is typically faster than filesystem I/O by quite a bit, which is
> why it's done this way.
Yes, paging from a dedicated page-partition is faster than reading in
the file from the filesystem, but there were a couple of compelling
reasons to do it the linux way.
- less wasted resources: why write out the page to a swap-partition when
we know it can be found on the filesystem anyway? With gcc and similar
big programs, swap-space need is probably reduced a lot by not using
swapping for clean pages.
- Ease of programming: the linux mm is very simple (1300 lines of C),
and I took shortcuts like not keeping track of old pages to get it
that way.
- If the swapspace is a file, not a partition (which seems pretty usual:
I have it set up that way myself), demand-loading is faster: no need
to write out the pages, and loading is quite as fast/slow.
That said, the current memory manager might have other problems which
makes it non-optimal as well: not keeping track of pages very much also
means the page-replacement algorithm is somewhat limited (understatement
of the year). I felt the simplicity made it worth it.
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Is it possible to disable ctrl-alt-del while running linux?
Message-ID: <1992Jun2.055143.27888@klaava.Helsinki.FI>
Date: 2 Jun 92 05:51:43 GMT
References: <KREJ.92Jun1205739@gaia.electrum.kth.se> <1992Jun1.203352.3388@src.umd.edu>
Distribution: comp
Organization: University of Helsinki
Lines: 52
In article <1992Jun1.203352.3388@src.umd.edu> chad@src.umd.edu (R Michael McMahon) writes:
>Yes. From kernel/sys.c:
>
>/*
> * this indicates wether you can reboot with ctrl-alt-del: the deault is yes
> */
>static int C_A_D = 1;
>
>Mike chad@src.umd.edu
Indeed. Here is a snippet of code that should enable/disable ctrl-alt-del:
----------
#define __LIBRARY__
#include <linux/unistd.h>
#include <stdio.h>
static _syscall3(int,reboot,int,magic,int,magigtoo,int,flag)
int main(int argc,char ** argv)
{
if (argc == 2)
if (!strcmp("on",argv[1])) {
reboot(0xfee1dead,672274793,1);
return 0;
} else if (!strcmp("off",argv[1])) {
reboot(0xfee1dead,672274793,0);
return 0;
} else if (!strcmp("now",argv[1])) {
for (argc=0 ; argc < 5 ; argc++) {
sync();
sleep(5);
}
reboot(0xfee1dead,672274793,0x01234567);
return 0;
}
fprintf(stderr,"usage: reboot [on|off|now]\n");
return 1;
}
----------
The program can only be run as root, or nothing will happen. Usage is:
reboot on - accept ctrl-alt-del (default)
reboot off - ctrl-alt-del is ignored
reboot now - reboot after syncing and waiting 25 seconds (so that you can ^C it)
And as with most code I write, none of the above has ever been tested: I
only guarantee that this is how I intended the reboot system call to
work.
Linus
===========================
===========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Is it possible to disable ctrl-alt-del while running linux?
Message-ID: <1992Jun2.055143.27888@klaava.Helsinki.FI>
Date: 2 Jun 92 05:51:43 GMT
References: <KREJ.92Jun1205739@gaia.electrum.kth.se> <1992Jun1.203352.3388@src.umd.edu>
Distribution: comp
Organization: University of Helsinki
Lines: 52
In article <1992Jun1.203352.3388@src.umd.edu> chad@src.umd.edu (R Michael McMahon) writes:
>Yes. From kernel/sys.c:
>
>/*
> * this indicates wether you can reboot with ctrl-alt-del: the deault is yes
> */
>static int C_A_D = 1;
>
>Mike chad@src.umd.edu
Indeed. Here is a snippet of code that should enable/disable ctrl-alt-del:
----------
#define __LIBRARY__
#include <linux/unistd.h>
#include <stdio.h>
static _syscall3(int,reboot,int,magic,int,magigtoo,int,flag)
int main(int argc,char ** argv)
{
if (argc == 2)
if (!strcmp("on",argv[1])) {
reboot(0xfee1dead,672274793,1);
return 0;
} else if (!strcmp("off",argv[1])) {
reboot(0xfee1dead,672274793,0);
return 0;
} else if (!strcmp("now",argv[1])) {
for (argc=0 ; argc < 5 ; argc++) {
sync();
sleep(5);
}
reboot(0xfee1dead,672274793,0x01234567);
return 0;
}
fprintf(stderr,"usage: reboot [on|off|now]\n");
return 1;
}
----------
The program can only be run as root, or nothing will happen. Usage is:
reboot on - accept ctrl-alt-del (default)
reboot off - ctrl-alt-del is ignored
reboot now - reboot after syncing and waiting 25 seconds (so that you can ^C it)
And as with most code I write, none of the above has ever been tested: I
only guarantee that this is how I intended the reboot system call to
work.
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Second patch to 0.96a
Message-ID: <1992Jun4.225621.23893@klaava.Helsinki.FI>
Date: 4 Jun 92 22:56:21 GMT
Organization: University of Helsinki
Lines: 43
I have just sent off the second patch to 0.96a: it should be on the
normal ftp-sites (nic, tsx-11 and banjo), although the only site which I
can make it directly readable on is banjo, so on the other sites it will
take the site-managers to make the patch available.
Patch 2 implements:
- itimers (by Darren Senn), which are now also used to implement the
alarm() system call.
- ultrastor scsi driver patches (by gentzel)
- [f]statfs() system call is implemented (so df can be made fs-
independent). Also some other minor fs-changes for the upcoming new
filesystem. Patches by Remy Card.
- preliminary core-file dumping code (linux creates a core-file, but
it's not in the correct format yet [*]).
- minor changes/bugfixes.
While patching in patch1 is a good idea for anybody, patch 2 isn't
really vital. I've made it available just so kernel hackers can keep up
with the kernel I have right now if they wish. Patch 2 is relative to
patch 1: you have to patch that in first.
[*] The current core-file is very simple, and the kernel code is there
just so that some enterprising character can expand it. A core-file
looks like this right now:
offset data
0x0000 "core-dump: regs=\n"
0x0040 struct pt_regs (see <sys/ptrace.c>)
0x0400 "floating-point regs:\n"
0x0440 struct i387 (see <linux/sched.h>)
0x0800 the first 1kB of user-space
Not very practical, but it /might/ help if the X-server dies of a
segmentation fault or similar (you can use pt_regs.eip to see where it
happened). The kernel code is very easy to change to accomodate for the
real core-file format, I just didn't know what it should be.
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: fsck flags to fix ailing filesystems?
Message-ID: <1992Jun5.083629.4527@klaava.Helsinki.FI>
Date: 5 Jun 92 08:36:29 GMT
References: <1992Jun4.222401.5390@mercury.unt.edu>
Organization: University of Helsinki
Lines: 46
In article <1992Jun4.222401.5390@mercury.unt.edu> kenc@sol (Ken Corey - Operator) writes:
>
>Interesting, fsck reports that larvsm are the flags it understands,
>but my man page on my (Sun4.1.1a) Unix machine a t work, and on
>my (mac)Minix don't show all those arguements.
Linux fsck is a quick hack, and not a very good program. I had hoped
somebody would expand it to do all the things a real fsck should do, but
it seems nobody else thinks it's an interesting project either.
The flags are similar to the minix fsck flags (as that's the only fsck
I've ever used), and are roughly as follows:
l - list all the files on the partition as you fsck. Not very practical,
but maybe you want to see what's going on.
r - repair any inconsistencies found, asking first if it's ok.
a - automatic repairs. Very simpleminded, but doing it by hand is
usually not worth it. If the problems are big enough that a doesn't
work, you might as well give up anyway under most circumstances.
v - verbose: print out some statistics.
s - show some super-block info
m - warn about the minix "mode not cleared" error: don't do this under
linux.
> The problem is that
>when I first got Linux, I also downloaded the unzip program.
> In the course of unzipping something, it trashed by /usr/root
>directory. Messing up the pointers somehow, so that the /usr/root
>directory could not be romoved.
Fsck doesn't handle bad directories at all, so the only thing you can do
in this case is to back up everything that seems ok, re-mkfs and
re-install that partition. If somebody has hacked fsck to work better
in these kinds of circumstances, I'd be interested to know.
As to why the errors happened, it certainly seems like a problem with
the scsi driver: I don't think it's a race in the fs-code, as this
doesn't seem to be a normal occurence. Could drew & co please
double-check?
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Problem with 0.96a Patch1 + Patch2
Keywords: linux
Message-ID: <1992Jun8.205908.20273@klaava.Helsinki.FI>
Date: 8 Jun 92 20:59:08 GMT
References: <arumble.707915342@extro.ucc.su.OZ.AU> <1992Jun7.142244.27874@ucunix.san.uc.edu> <1992Jun8.120946@banner.ucsc.edu>
Organization: University of Helsinki
Lines: 27
In article <1992Jun8.120946@banner.ucsc.edu> sinster@scintilla.capitola.ca.us writes:
>In article <1992Jun7.142244.27874@ucunix.san.uc.edu>, zuazaga@ucunix.san.uc.edu (Humberto Ortiz-Zuazaga) writes:
>>
>> What about itimer.c? I kept mine in kernel, and changed the lib/Makefile.
>
>What? What about itimer.c? There should be _two_ files called itimer.c.
>One is lib/itimer.c (this is the library interface to itimers) and the
>other is kernel/itimer.c (this actually implements the itimers).
>
>Is there something odd about the patch?
Yes, there is something odd about the patch - lib/itimer.c isn't there.
It's not really needed (it's not really kernel code at all), and the
only problem is that the lib/Makefile mentions it. I didn't really look
through the patch when I made it...
As people have noticed, there are several ways to overcome this problem
with patch2: the preferred method is just to do a "touch lib/itimer.c"
which should make everything work ok. Alternatively, you can edit the
makefile and remove "itimer.o" from the OBJS-line.
Linus
PS. I sometimes get mail I cannot respond to: the latest was from Paul
Fraley. If your mailer doesn't set the correct from or reply-to fields,
please add a known good email-address to the body of the mail. While it
won't guarantee an answer, it at least makes it possible.
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: itimer bit me yet again!
Message-ID: <1992Jun10.061543.27737@klaava.Helsinki.FI>
Date: 10 Jun 92 06:15:43 GMT
References: <1992Jun10.023016.24003@mercury.unt.edu>
Organization: University of Helsinki
Lines: 20
In article <1992Jun10.023016.24003@mercury.unt.edu> kenc@sol (Ken Corey - Operator) writes:
>Okay, I give up. I got the itimer.c file sent out by Dean the other
>day...put it in /usr/src/linux/kernel, made sure there WAS a reference to it
>in kernel/Makefile, and that there WASN'T a reference to it in lib/Makefile.
You did all three things that could fix the problem on their own, but
when done all together they break the kernel horribly, as you saw.
The original kernel/itimer.c shouldn't be moved: it's indeed a kernel
source-file, and contains the sys_[get|set]itimer system call
definitions.
lib/itimer.c should either (a) not exists: only in that case you should
remove the itimer.o from the Makefile, (b) be empty or (c) be the file
sinister sent out yesterday. Whichever of these you choose, it's not
linked into the kernel anyway, so it doesn't matter from a kernel
standpoint: but you can use lib/itimer.o from user space as it
implements the itimer library stubs.
Linus
===========================
===========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: logging the printk output
Message-ID: <1992Jun11.102559.295@klaava.Helsinki.FI>
Date: 11 Jun 92 10:25:59 GMT
References: <3195@sicsun.epfl.ch>
Organization: University of Helsinki
Lines: 64
In article <3195@sicsun.epfl.ch> lecom@slhp1.epfl.ch (Claude Lecommandeur) writes:
>
> How can one log the output of all the printk output in a file
>(some kind of syslog) ? I'm trying to debug a driver, but all the
>good things disapear above the screen.
There is no 100% sure way to log the printk() messages, as printk() may
not sleep or even pause, but there is already a syslog capability in the
kernel that captures everything printed under normal load. It may fail
if the buffer fills up without being read by some process, but that is
usually not a problem.
Here is a program that uses the kernel logging features:
#define __LIBRARY__
#include <unistd.h>
#include <string.h>
#include <stdio.h>
#include <errno.h>
static _syscall3(int,syslog,int,type,char *,buf,int,size)
char buffer[1024];
int main(int argc, char ** argv)
{
int i;
errno = 0;
if (argc == 2 && !strcmp("off",argv[1]))
syslog(0,0,0);
else if (argc == 2 && !strcmp("on",argv[1]))
syslog(1,0,0);
else if (argc == 1)
while (1) {
i = syslog(2,buffer,1024);
if (i < 0)
if (errno == EINTR)
continue;
else
break;
write(1,buffer,i);
}
if (errno)
perror("syslog");
return errno;
}
Usage is:
syslog on - start logging
syslog off - end logging
syslog - print the log-messages to stdout until interrupted.
for example, under X you can use it to see the log-messages like this:
# syslog on
# xterm -e syslog &
Which will make you a log-window that you can use to see what the kernel
prints out while using X.
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: what's the kernel need for v 1.0
Message-ID: <1992Jun12.090719.24960@klaava.Helsinki.FI>
Date: 12 Jun 92 09:07:19 GMT
References: <1992Jun11.203410.15552@athena.mit.edu> <1992Jun12.074133.17546@mnemosyne.cs.du.edu>
Organization: University of Helsinki
Lines: 57
In article <1992Jun12.074133.17546@mnemosyne.cs.du.edu> zmbenhal@isis.cs.du.edu (Zeyd M. Ben-Halim) writes:
>Thomas Dunbar <tdunbar@vttcf.cc.vt.edu> writes:
>>What is expected in the kernel in v. .97 ... 1.0? Back in v .11, i felt i
>>knew more-or-less what was going to be done. Now, other than stablization of
>>GCC, X and the kernel, what's needed? Other than tcp/ip, which i don't care
>>much about myself (but who IS working on this?), what's missing?
>> i'd like to see a version number soon that suggests Linux, as a whole,
>>is no longer in beta-test.
Ok, I already answered tdunbar by mail, but in case others are
interested:
>How about finished VFS layer (or is it already?)
The vfs layer is already pretty finished: there should be no more big
rewrites as in the 0.95-0.96 diffs. Tweaking etc will naturally go on
(as with any other kernel feature), but it's mostly there.
>shared memory
>semaphores
>ipc messages
I'd like these eventually, and I might try to implement them during the
summer, but no promises. In any case these certainly aren't required for
a 1.0 version.
>file and memory locks
Well... I'm not too hot about file locking, but we'll see.
>named pipes
This is already available as a patch. I haven't applied it yet, but I
will as soon as the author feels it's ready (and I agree).
>STREAMS
>screen mapping with page faults on bank crossing (video card dependant :-(
>AF_INET sockets
Not me. Hopefully somebody else implements it so cleanly that I cannot
do other than accept it :-)
>Any fs besides minix
Definitely. This is one of the points keeping linux beta. 0.97 should
contain it.
>What Linux NEEDS is a stable GCC (one that does not evolvo every 2 days) and
>an easy method of updated shared libs (jump tables or whatever)
Yes. And easier installation. And manuals/guides/whetever. I know I
have been hoping to make 1.0 available for a long time - right now I
expect it to be here by the end of summer. By that time gcc and the
libraries should have stabilized, and hopefully the ABC-release or
similar is ready.
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Patch2 is a bad patch if it doesn't compile
Message-ID: <1992Jun13.074121.21900@klaava.Helsinki.FI>
Date: 13 Jun 92 07:41:21 GMT
References: <myddryn.707907410@hal> <1992Jun9.163918@dana.ucsc.edu> <1992Jun12.143353.2356@aw2.fsl.ca.boeing.com>
Organization: University of Helsinki
Lines: 28
In article <1992Jun12.143353.2356@aw2.fsl.ca.boeing.com> vds7789@aw2.fsl.ca.boeing.com (Vincent D. Skahan) writes:
>
>Could Linus please either release a patch3 so that we're up at the
>current version and can just hit 'make' or release a patched-up 'good'
>set of sources ???
Patch3 won't be out before there is some good reason for it: right now I
haven't changed the sources enough to warrant it.
>I thought the whole point of releasing a patch was to permit people
>to get to the same baseline version to work off of...
>
>I'm not installing anything above patch1 if I have to tweak anything
>to get it to compile...
This is the normal reasons for patches, but patch2 was a bit special,
and documented as such: the /major/ reason for the release was just to
make the preliminary core-dumping code available to kernel hackers, so
that somebody who had better docs etc than me could implement the
correct format for core-files. This indeed happened, and the next
release will have post-morted debugging (and hopefully attach and
detach).
So if people don't feel comfortable with patching, patch2 can safely be
left out (although it does fix some minor bugs as well: the open()
error-value etc).
Linus
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux and Me II
Message-ID: <1992Jun13.081917.22210@klaava.Helsinki.FI>
Date: 13 Jun 92 08:19:17 GMT
References: <BURLEY.92Jun12181253@geech.gnu.ai.mit.edu> <BURLEY.92Jun12193201@geech.gnu.ai.mit.edu>
Distribution: comp
Organization: University of Helsinki
Lines: 14
In article <BURLEY.92Jun12193201@geech.gnu.ai.mit.edu> burley@geech.gnu.ai.mit.edu (Craig Burley) writes:
>
>The upshot is that it looks like the files are all okay on disk, but that
>sometimes Linux misreads the data, convincing diff that files are different
>when they aren't. The differences seem more suggestive to me of block-level
>(OS-interface-level) problems, though since I haven't looked at how diff is
>implemented, I cannot be sure it isn't a diff bug (though it'd have to be
>a random bug).
It's something in the SCSI drivers, and I'd suggest getting the newest
drivers from headrest.woz.colorado.edu: they might correct the problem.
Obviously, I haven't tested them...
Linus
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: mtools question
Message-ID: <1992Jun15.105210.7613@klaava.Helsinki.FI>
Date: 15 Jun 92 10:52:10 GMT
References: <1992Jun14.025750.2388@CSD-NewsHost.Stanford.EDU> <1992Jun14.190521.12355@bernina.ethz.ch> <1992Jun14.225856.27315@unixland.natick.ma.us>
Organization: University of Helsinki
Lines: 13
In article <1992Jun14.225856.27315@unixland.natick.ma.us> bill@unixland.natick.ma.us (Bill Heiser) writes:
>almesber@nessie.cs.id.ethz.ch (Werner Almesberger) writes:
>>>> Hard links have the advantage that they only occupy an inode each while
>>>> symbolic links additionally consume one disk block (1kB).
>
>Is this meant to imply that LINUX has symbolic links?
Indeed. Has had them since 0.12 I do believe. I think the original
0.12 didn't allow symlinks that contained other symlinks as part of
them, but later versions have had a loop count of five, which is quite
enough for everything I have yet seen.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: anyone using 20 MB RAM?
Message-ID: <1992Jun15.191710.20349@klaava.Helsinki.FI>
Date: 15 Jun 92 19:17:10 GMT
References: <PNAKADA.92Jun15101715@pnakada.oracle.com>
Distribution: comp
Organization: University of Helsinki
Lines: 22
In article <PNAKADA.92Jun15101715@pnakada.oracle.com> pnakada@oracle.com (Paul Nakada) writes:
>
>Linux Hackers -
>
> I'd like to add 4 4MB SIMMS to my system for a total of 20 MB RAM.
>Does anyone have Linux running with this amount of memory? Are there
>any gotchas I should know about? Thanks.
The standard linux distribution uses memory only up to the 16MB mark;
you'd have 4MB unused (but it's still a great idea). There is a 32MB
patch (mainly just sets up a few more page tables), but it won't work
with the current SCSI-drivers I think.
The reason 16MB is a problem is that DMA won't go beyond that, and
although the floppy-driver is coded to take care of this, I don't think
the scsi drivers are (there was a problem with going above 2MB with the
0.95 scsi release with some card). If you don't use swapping (and with
20MB you can run a lot even without swapping), linux won't try to copy
directly to the >16MB pages anyway, so the 32MB patch is safe in that
case. Likewise if you aren't using scsi.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: patch3....
Keywords: patch 0.96a
Message-ID: <1992Jun15.200454.21058@klaava.Helsinki.FI>
Date: 15 Jun 92 20:04:54 GMT
Organization: University of Helsinki
Lines: 43
Ok, I already announced it on the kernel mailing-list, but I might as
well go all the way. I put out patch3 to 0.96a yesterday, and it's
available on banjo in pub/Linux/Linus, and I'll upload it to the other
normal ftp-sites tonight.
NOTE! Patch3 is (like patch2) more of a kernel-hacker patch: it's just
in case you want to keep up with my kernel. It has some problems with
some serial lines, and if you experience them, I'd like to know what
type of chip you are running (and what linux reports on bootup). If you
don't think patching the kernel is fun, you might as well forget this
and wait for a real release (next month?).
Patch 3 contains:
- support for attaching and detaching processes under gdb (but you need
a gdb that knows about this).
- 16550A support
- full core-dumping (again, you need a gdb that supports it)
- sockets have no problems with non-root binding etc
- /dev/zero implemented (mknod /dev/zero c 1 5)
None of the patches are very big (the whole patch is 17kB compressed,
most of it attach/detach code), but they are all pretty useful.
The 16550A support means that with the appropriate chip you now should
be able to use the serial ports at much higher speeds, but as mentioned,
it seems to break on some machines.
The detaching isn't perfect yet (I noticed only after making the diffs
that I had forgotten to do some cleanups), but it's not generally a
problem (the code just forgets to give the process back to it's rightful
father).
The patch is relative to the pl2 kernel, so you have to use the earlier
patches first. This time, I've added the lib/itimer.c code.
16550A support was written by tdavis, the correct format of the
core-dumps was written by eric (who also wrote the attach/detach code I
used as an example when implementing it), /dev/zero was written by
almesber. Nice to see good patches: I just did the socket-thing and
rewrote the attaching to suit me.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: get/setitimer()
Message-ID: <1992Jun15.223433.23669@klaava.Helsinki.FI>
Date: 15 Jun 92 22:34:33 GMT
References: <708635438snx@hectic.demon.co.uk>
Organization: University of Helsinki
Lines: 23
In article <708635438snx@hectic.demon.co.uk> mike@hectic.demon.co.uk (Mike Davies) writes:
>Now that X seems to be well established on Linux ... (flame proof
>suit at the ready) ... I've tried to compile a couple of contributions,
>with a varying amount of success.
>
>However, a stumbling block in at least one case is setitimer().
>Have I missed something (quite likely), or this still missing in Linux ?
>If so, is it likely to appear shortly ? If not, is there a work-round ?
set/getitimer doesn't exist in the basic 0.96a kernel, but after
applying all the patches (1-3) it should work well. The only thing I
have which actually uses it is xneko, so I haven't tested it to
exhaustion.. Note that code that uses get/setitimer also often assume
the BSD signal() behavior instead of the linux (posix) stuff, so you
might have to edit the sigblocking functions and rewrite signal() calls
to use sigaction().
The get/setitimer() library stubs are now in patch3, and you have to add
them to the library in order for programs using them to link ok (ie add
the lib/itimer.o file that gets created by a kernel make to the static
libc.a. Maybe the newer gcc-2 libraries already have it).
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: linux scheduling
Message-ID: <1992Jun15.231313.24182@klaava.Helsinki.FI>
Date: 15 Jun 92 23:13:13 GMT
References: <PNAKADA.92Jun15132016@pnakada.oracle.com>
Organization: University of Helsinki
Lines: 99
In article <PNAKADA.92Jun15132016@pnakada.oracle.com> pnakada@oracle.com (Paul Nakada) writes:
>
>Could someone (linus?) please give a high level description of the
>scheduling mechanism in Linux?
The scheduler in linux is pretty simple, but does a reasonably good job
at giving good IO response while not being too unfair against cpu-bound
processes. Simply put:
Linux gets a timer-interrupt at every jiffy (100 Hz), and decrements the
current->counter. If current->counter is zero, and the process isn't
running in kernel mode, the scheduler() is called. Also, when a process
is woken up and it's counter is greater than the current process, a flag
is set, which forces the re-scheduling.
The scheduling is pretty simple: when schedule() is called, the process
that has the highest non-zero counter and is runnable is run. If no
runnable process exists, task[0] ("swapper") gets to run, but it
currently doesn't do anything. In the future, the swapper task might do
page-aging or similar.
If all runnable processes have a zero counter, the schedule() algorithm
goes through all processes once more, giving them a new counter-value of
"priority+counter/2". It might seem useless to add the counter/2, as
counter is 0, but in fact this is done to /all/ processes, including
sleeping ones, which thereby get higher counter-values for when they
wake up.
The above algorithm seems to be pretty fair, and works well while being
very easy to understand. It also gives much snappier response than many
systems I've seen. And it's all done without any queues at all, which I
find clean and simple. In fact, the scedule() algorithm isn't more than
a couple of lines in C, and going to sleep or waking up is just a matter
of setting the process status and calling schedule().
>a) a process calls a kernel trap;
>b) process enters kernel mode, current processor state saved.
In fact, the current processor state is never saved anywhere as in
"normal" unices. A kernel trap under linux is very much like a system
call: registers get saved on the stack as needed, but we don't mess
around with updating task-structures etc.
>c) pop return address from stack and save
No, let it lie on the stack: when the process returns it gets restored.
Why save it anywhere else?
>d) kernel initiates disk i/o and places process on i/o queue
>e) get next active process
>f) push return address on stack and return from handler to new process
>g) process times out
> etc etc etc.
It's all much simpler than this: the process, running in kernel mode,
does what it wants, and if it wants to sleep, it just does
current->state = TASK_INTERRUPTIBLE;
schedule();
assuming it has made sure it will wake up some way (due to signals or
the kernel time-out feature or by putting the task-struct address in a
wait-variable). The other processes run happily in between, and when
something causes the process to wake up, it just continues after the
schedule() call.
When it's done all the things the system call (or page-exception or
whetever) required it to do, it just does a return, and it's back in
user mode.
As to how schedule() switches tasks, it's builtin in the 386, so it's
actually just a couple machine-code instructions. It's slightly more
complicated than just a jump through a task-segment, as it checks that
it's not the same task, and for minimal 387-saving by testing the
"last_task_used_math" variable and doing a clts if possible, but it's
still less than 10 insns. To understand what /really/ goes on, you'd
better read a 386 book, but it's not too complicated if you just care
about the general idea.
>why do i ask this? I've been studying the scheduling code for a
>couple days, trying to absorb enough to take a stab at improving
>response time under heavy disk i/o. I can understand the parts as
>separate modules, but it's not obvious to me how they work together as
>a system. I imagine it's second nature to Linus and other veteran
>kernel hackers, but all I've got is an OS class from a few years back.
I doubt the scheduler is the problem when it comes to response-time
under heavy disk i/o. It's probably at least partly because of the way
buffer-cache blocks are locked, which sometimes forces the buffer
algorithms to sleep on them unnecessarily. Thus if a buffer-request
comes through when blocks are locked due to actual IO, the request
sometimes blocks just to make sure there are no races.
I'd take a look at fs/buffer.c before doing anything else. But be
/very/ careful when changing buffer.c: it's very easy to add a
race-condition if you don't think of all the possible things that can
happen due to interrupts etc while a buffer is searced for.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Size-change of ino_t
Message-ID: <1992Jun16.161638.20159@klaava.Helsinki.FI>
Date: 16 Jun 92 16:16:38 GMT
Organization: University of Helsinki
Lines: 37
With the eventual advent of bigger filesystems (and a DOS filesystem is
being developed), ino_t (currently unsigned short) is no longer really
big enough. 65535 (0 is reserved) inode numbers might be too little on
bigger filesystems, and the DOS filesystem will use sparse inode numbers
that will require more than 16 bits in order to be efficient.
No problem: just change it. Right? Wrong. That will also change the
size and offsets in the 'stat' struct (<sys/stat.h>), which is used by
almost every program currently in use. While recompiling /everything/
might be a good idea, even gcc won't probably run, so it would have to
be done by a kind of cross-compilation from the current linux version to
the new version. That's simply not practical.
What I intend to do is to keep the old stat() system call and return
just the low 16 bits of the inode number in it (might still break under
bigger fs's, but it's very unlikely, and only on a user level), and
create a new stat (and fstat) system call that has the full information.
Ugly, but with the current installed base it's impractical to do any
other way (in 0.11 I would probably have gone all the way and simply
recompiled everything).
Why post here? Two reasons: (1) I want to know if people feel there are
other structures that really /need/ to be upgraded (for future
expansion), so that I won't have to have several different stat()
interfaces, and (2) just to warn people about it, and maybe get some
comments.
Note that while a lot of programs use the stat() system call, they
usually don't actually care about the inode number, so it's not
essential that all programs be recompiled. Things that actually /need/
the full inode number include tar (uses i to verify if two files are
actually had-linked together), pwd (find the root that way) and and to a
lesser extent things like cpp ('#pragma once' uses it, I believe). Old
binaries of these programs might become unreliable when/if somebody
actually gets a filesystem that uses more than 65535 inodes.
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Floppy errors at end of disk (Re: Aachen binaries now at rs6000.cmp.ilstu.edu)
Message-ID: <1992Jun16.195611.24568@klaava.Helsinki.FI>
Date: 16 Jun 92 19:56:11 GMT
References: <1992Jun15.180815.12006@rs6000.cmp.ilstu.edu> <1992Jun16.152453.29511@tc.cornell.edu> <1992Jun16.192910.17381@rs6000.cmp.ilstu.edu>
Organization: University of Helsinki
Lines: 14
In article <1992Jun16.192910.17381@rs6000.cmp.ilstu.edu> jliddle@rs6000.cmp.ilstu.edu (Jean Liddle) writes:
>
>Anyone know why this might be? I am using the Adaptec 1542b floppy
>controller built into the card, and get block read errors at the end of
>each disk. This also happened during mkfs at block 65536 on my hard drive,
>even though I specified "mkfs -c /dev/sd02 65535." Its as though linux
>doesn't stop reading/writing when it reaches the end of the disk...
Yes, it's a problem with the read-ahead routines that read ahead past
the end of the disk... It's fixed in patch2, I think (and if it isn't
it's in patch3), but it's totally harmless except for the error
messages, so you can ignore them if you wish.
Linus
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 32-bit inodes: patch4
Message-ID: <1992Jun18.145012.17636@klaava.Helsinki.FI>
Date: 18 Jun 92 14:50:12 GMT
Organization: University of Helsinki
Lines: 12
Ok, patch4 implements 32-bit inode numbers (and thus the new
stat/lstat/fstat system calls), as well as correcting the bad
rs-performance on some machines that showed up in patch3. It's
currently only on banjo, but I'll copy it around eventually.
Again, you don't miss much if you don't use this patch: it's mainly for
(a) the serial problems and (b) for hlu etc that want to test out the
32-bit interface. It does some other magical tricks as well (uses less
memory in the low 1M region by moving the screen and tty buffer to high
memory), if anybody is interested.
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: ET4000 speedup (was Re: 16 bit video access on systems with additional monochrome adapter)
Message-ID: <1992Jun19.124336.8707@klaava.Helsinki.FI>
Date: 19 Jun 92 12:43:36 GMT
References: <1992Jun18.201538.15449@athena.mit.edu> <1992Jun18.210717.19512@serval.net.wsu.edu>
Organization: University of Helsinki
Lines: 28
In article <1992Jun18.210717.19512@serval.net.wsu.edu> hlu@phys1.physics.wsu.edu (Hongjiu Lu) writes:
>In article <1992Jun18.201538.15449@athena.mit.edu>, arybicki.lax1b@xerox.com writes:
>|>
>|> While on the subject. Does X386 for Linux have the ET4000 speedups from
>|> export.lcs.mit.edu? I've heard that they greatly improve the performance of
>|> X386 drawing. They would definitely make xmartin work quicker.
>
>I don't if I want it. From my understanding, it only supports 1024x1024.
No, they only limit the /virtual/ screen size to 1024xXXX, which means
that you can't run with screens wider than 1024 pixels, but that's
usually no problem. Having a 800x600 resolution mode should be quite
possible tiwh the speedup patches (but you'll need 1MB video-ram, as
minimum virtual resolution is 1024x600 in that case).
The reason for the above limit is that that there are no pixel-lines
that are partly in one segment, and partly in another, so checking for
VGA segments is much reduced, giving faster routines. The original X386
routines as more general, but have the obvious speed disadvantages:
(S)VGA isn't a very good graphics implementation.
I think the speedup patch is actually in the X386-1.2e version that is
currently in beta-testing (not under linux yet, though), so eventually
we'll see a release that supports the faster ET4000 modes as well. I
don't know if obz has the beta-test release, or if he will be able to
use it in the near future, so don't hold your breath.
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Linux v 0.96b available
Keywords: new version 0.96b
Message-ID: <1992Jun21.231223.18826@klaava.Helsinki.FI>
Date: 21 Jun 92 23:12:23 GMT
Organization: University of Helsinki
Lines: 59
I have uploaded my newest kernel sources and a US-keyboard image to both
tsx-11.mit.edu and nic.funet.fi. I'll put it on banjo too as soon as
banjo wakes up (that's when I'll do the patches too: I'll need access to
banjo to get a 0.96a.pl4 kernel to make patches against..). As usual,
it will probably be a day or two until the files have been moved from
the incoming directory to their proper places.
0.96b is not a new major release: it's pretty close to 0.96a with all my
patches (1-4). However, as there has been 4 patches already, I decided
it would be time for a full kernel release along with a bootimage, so
that people who don't feel confident with patching can use the new
features.
If you already have 0.96a patchlevel 4, 0.96b will offer you these new
features:
- the math-emulation now handles fsqrt, as gcc-2.2.2 generates that
inline. I haven't tested the kernel code at all: I tested the
algorithm in user space, but I'm lazy, so I never turned off my 387
to do real testing. I hope it works.
- better vt100 terminal emulation thanks to Mika Liljeberg.
- I removed a possible race-condition in the buffer-cache code.
- minor fixes
The vt100 emulation should now be complete enough for almost everything
(including vt100 test suites): as a result the setterm utility had to be
changed (as the old setterm codes aren't compatible with the full vt100
codes). setterm-0.96b.tar.Z contains the new setterm.
The soon-to-be-released gcc-2.2.2 will need the 0.96b kernel: (a) due to
the fsqrt emulation and (b) it uses the new stat() system call. So
upgrading is a good idea. (If you have a co-processor, (a) isn't used,
but (b) still stands)
If you have an unpatched 0.96a, the differences to 0.96b are roughly
(not counting the above-mentioned new things):
- corrected the disk-buffer-list bug with read/write-errors
- fixed read-ahead warning messages at end of disk
- better support for text-mode restoration after running MGR and X
- full core-dumping, attach/detach etc debugging features
- 16550A support
- less low 1MB memory used for kernel structures
- various minor fixes
Note that the fact that new versions (pl4 and above) use more memory in
the 1M+ area means that linux will report less free memory (it's used
for buffer-cache instead). This could concievably be a problem on 2MB
machines. The standard kernel comes with only 4 pty's though, and if
you use the standard 80x25 text modes instead of svga modes, the VC
buffers will be smaller. Please contact me if there are problems even
with this minimal setup.
0.96b does /not/ contain: the new scsi drivers, new filesystems or some
other patches I have gotten (ibm character set mode, loop-devices etc).
If you have sent me any other patch, you might want to remind me about
it.
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 32-bit i-nodes???
Message-ID: <1992Jun22.211849.15768@klaava.Helsinki.FI>
Date: 22 Jun 92 21:18:49 GMT
References: <1992Jun22.191501.5047@athena.mit.edu>
Organization: University of Helsinki
Lines: 30
In article <1992Jun22.191501.5047@athena.mit.edu> williamsem"%mrgate."netspo.a1.decnet@space.laafb.af.mil writes:
>
>A few days ago, I saw the announcement of 0.96a patch 4 that included (among
>other things) 32-bit i-nodes. I looked in the patch and saw the new stat
>functions and the new syscall numbers, but couldn't really see what had
>changed.
Not too surprising: the changes are just to make future filesystems
easier to write. The current filesystem still uses only 16 bits for the
inode numbers, and the changes were just the internal representation
(and the new system call interface so that things will work when the new
filesystems arrive).
> In particular, what impact does this have on the disk itself? What
>really confused me is that the 32-bit i-node feature was not listed in the
>0.96b announcement today! Could someone please clarify what the 32-bit I-node
>change really did?
Sorry about the lack of mention in the 0.96b announcement: the 32bit
inode numbers are definitely in, and I just forgot to mention it (it
wasn't any of the really /new/ features.
What the 32-bit change really did was to make it possible for persons
writing new filesystems to use more info to specify an inode: this was
needed at least for the DOS fs. I hope this means that 1.0 will be able
to mount DOS filesystems, and the mtools package will be a thing of the
past. It has no immediate impact on anybody else than hlu, who had to
update the libraries (gcc-2.2.2 will use the new interface).
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Too much uneaten serial causes system hang?
Keywords: LINUX serial ports, uneaten characters
Message-ID: <1992Jun23.172824.16843@klaava.Helsinki.FI>
Date: 23 Jun 92 17:28:24 GMT
References: <1992Jun23.140938.5621@cseg03.uark.edu> <arumble.709312764@extro.ucc.su.OZ.AU>
Organization: University of Helsinki
Lines: 26
In article <arumble.709312764@extro.ucc.su.OZ.AU> arumble@extro.ucc.su.OZ.AU (Anthony Rumble) writes:
>
>YES! I have noticed this VERY exact thing also!
Oh, well: it's a bug in the serial drivers that I have already fixed,
but I haven't done the c-diffs yet. I have rewritten big parts of the
serial line code to be more easily configured for different IRQ numbers,
and I noticed the bug while doing that. I'll make patch1 for 0.96b
available later today or tomorrow.
patch1 will be mostly just the serial driver code: it allows changing
the irq's (and port addresses) of serial devices on the fly (with an
ioctl call), so people that have ser4 on irq5 etc shouldn't have to
recompile the kernel. It also returns EBUSY if you try to open a serial
line that shares the irq-line with another line etc.
Another change in patch1 will the the handling of ctrl-alt-del: it will
send a SIGINT to the init process if the reset-function is disabled.
This makes it ideal for a controlled shutdown, but it does need a
/bin/init that knows about this.
Linus
PS. It seems both the DOS-fs and the extended fs will be out for
alpha-testing next week, so I assume 0.97 will have them both if things
work out ok.
==================
==================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: FAQ-finding mission 2: demand paging
Message-ID: <1992Jun24.100236.5849@klaava.Helsinki.FI>
Date: 24 Jun 92 10:02:36 GMT
References: <Bq9DvI.GD9@world.std.com> <1992Jun22.215658.13564@colorado.edu> <HERMIT.92Jun23185304@dastari.uucp>
Organization: University of Helsinki
Lines: 25
In article <HERMIT.92Jun23185304@dastari.uucp> hermit%dastari.uucp@devon.lns.pa.us writes:
>
>You shouldn't be able to write to a demand-paged executable that is
>being executed. An open for writing should return ETXTBSY in that
>case. (creat() should also fail, I imagine.)
Linux doesn't care, and indeed there is no difference between opening a
normal file and opening a file for demand-paging. I don't think ETXTBSY
is worth any extra code: (a) it doesn't happen in practice and (b) if it
does: so what. If you have write permissions to your executables and
overwrite them with something else, you deserve everything that's coming
to you. If somebody writes patches to add the ETXTBSY detection, I
might use them if I feel they are clean enough, but I certainly am not
going to implement it. I've used demand-paging on linux for six months
(that's pretty exactly how long it has been in there), and I have never
seen any problem with it.
Similarly with the swap-space file (and shared libraries). If somebody
overwrites swap data the kernel doesn't care: your user-space programs
might not do too well, though. Swapspace and binaries should be
non-writeable by normal users (and at least swapspace should be
non-readable), and if you are root you can hose the system more easily
than by overwriting binaries.
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Problems compiling & escape sequences
Message-ID: <1992Jun24.131806.10059@klaava.Helsinki.FI>
Date: 24 Jun 92 13:18:06 GMT
References: <92175.235813U30207@uicvm.uic.edu>
Organization: University of Helsinki
Lines: 26
In article <92175.235813U30207@uicvm.uic.edu> U30207@uicvm.uic.edu (Harry Georgopoulos) writes:
>
> [ sending escape sequences to the printer ]
Assuming you have bash, the easiest way to send escape-sequences to the
printer is:
$ echo -e -n "\033E" > /dev/lp1
sends the sequence ESC + 'E' (usually "emphasize on") to thelp device.
The "-e" means that echo uses the escape sequences (\033 = dec 27 = esc
= ^[), and the "-n" means that the echo doesn't send a newline.
>gcc -O -g -o basename basename.o ../lib/libshu.a version.o
>ld:No such file or directory for libg.a
>make[1]: *** [basename] Error 1
This comes up with some regularity: 2.2.2 has a libg.a, but earlier
versions didn't. You can either compile without the "-g" flag, which
makes debugging pretty much impossible (but makes the binaries much
smaller), or create a dummy libg.a in the library subdirectory (which is
different depending on which gcc version you have: try /usr/lib/static
or /usr/lib/lib-gcc/i386-linux/2.2 or similar depending on the version.
The dummy libg.a is created with "ar cvs libg.a".
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Bug in fsqrt emulation
Message-ID: <1992Jun25.115206.8160@klaava.Helsinki.FI>
Date: 25 Jun 92 11:52:06 GMT
Organization: University of Helsinki
Lines: 35
I won't make a patch2 for this one, but 0.96b(.pl1) has a one-character
bug in the fsqrt emulation code that results in fsqrt resulting in zero
all the time. The following patch corrects it (thanks to Rick Sladkey
for noting it: I hadn't tested the code, so I never saw it...)
---------- cut cut ----------
--- sqrt.c.orig Thu Jun 25 00:00:00 1992
+++ sqrt.c Wed Jun 24 23:59:37 1992
@@ -55,7 +55,7 @@
src[3] = s->b;
d->exponent = 0;
d->a = d->b = 0;
- if (exponent) /* fsqrt(0.0) = 0.0 */
+ if (!exponent) /* fsqrt(0.0) = 0.0 */
return;
if (!src[2] && !src[3])
return;
---------- cut cut ----------
That is, add the missing '!' and recompile the kernel. This bug
naturally doesn't show up on machines with a co-processor, and isn't
noticeable unless you have programs compiled with gcc versions > 2.1, as
earlier versions didn't use the fsqrt instruction.
At least one other known bug in 0.96b.pl1 is that a serial line open
that fails due to EBUSY (ie another serial line using the same irq-line
is active) will still incorrectly add 1 to the tty->count. You don't
usually see this bug, but it can result in bogus EBUSY errors later on.
This and the fsqrt bug are already fixed in my version, and I'll make
patch2 available when I have some more fixes.
Other things added by patch2 will include correct CS5-8 and parity
handling on the serial lines (and HUP on setting the speed to 0).
Linus
============================
============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Logitech mice problem revisited.
Message-ID: <1992Jun25.123636.9214@klaava.Helsinki.FI>
Date: 25 Jun 92 12:36:36 GMT
References: <3264@sicsun.epfl.ch>
Organization: University of Helsinki
Lines: 29
In article <3264@sicsun.epfl.ch> lecom@slhp1.epfl.ch (Claude Lecommandeur) writes:
>
> I did much investigation on why my logitech mouse (MouseMan M-MC13)
>doesn't work with X11. This mouse is supposed to be Microsoft compatable
>but isn't. The normal sequence (microsoft) for button1 click without
>moving is hexa : 60 0 0 (seven bits, no parity, 2 stop bits) i verified
>it is true with another microsoft compatable mouse (genius). But the
>logitech one send, (or at least i read on /dev/ttys1) : 60 40 40.
>
> This mean that the seventh bit on the 2 last bytes are set to one
>and they should be set 0. I was told by Logitech that actually, there
>is a difference between their mice and microsoft : there is only one
>stop bit instead of two. But setting -cstopb does nothing at all.
Ok, it does indeed seem to be the bad support for CS7 in the linux
kernel. It seems I'll have to make patch2 available earlier than I
thought: I have implemented full CS7 support now, and if that is what it
takes to get some mice to work with linux, patch2 should correct it.
Expect the new patch tomorrow.
Thanks for a good report: these kinds of things really help when it
comes to correcting kernel features. As it happened, I added the
support before I saw this post, but that's just luck.
Patch 2 also supports the CSTOPB bit, which earlier linux versions
ignore (along with PARENB/PARODD and the CSx settings). I hope the mice
problems will be gone after this patch.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.96b PL2 Pty's broken?
Message-ID: <1992Jun28.071057.14601@klaava.Helsinki.FI>
Date: 28 Jun 92 07:10:57 GMT
References: <1992Jun27.202738.7487@bmerh85.bnr.ca>
Organization: University of Helsinki
Lines: 20
In article <1992Jun27.202738.7487@bmerh85.bnr.ca> dgraham@bmers30.bnr.ca (Douglas Graham) writes:
>Was there a reason why the following patch was applied to the read_chan
>code in 0.96b PL2? Now, a "cat /dev/ttyp0" will return immediately after
>having read 0 bytes, instead of hanging waiting for something to be
>written to the master side. Among other things, this breaks "script".
[ patch which returns 0 in read() if the other end of a pty is not open ]
I got a report that the above was the correct behaviour, so when I
implemented it and nothing I used broke, I added it to patch2. It seems
it wasn't the right thing to do. I'd like to know the correct
behaviour, so if you have documentation, please tell me how a pty should
react to read, write and open when the other end isn'c open yet.
I also changed the open() on a pty slave to wait until the master is
opened, but I put a #if 0 ... #endif around it (see chr_drv/pty.c), so
it isn't used right now. Could someone please mail me the correct
semantics for these cases?
Linus
==============================
==============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: writing 96b image to floppy
Message-ID: <1992Jun28.065802.14240@klaava.Helsinki.FI>
Date: 28 Jun 92 06:58:02 GMT
References: <74577@ut-emx.uucp> <709500596snx@hectic.demon.co.uk>
Organization: University of Helsinki
Lines: 15
In article <709500596snx@hectic.demon.co.uk> mike@hectic.demon.co.uk (Mike Davies) writes:
>
>I'm getting worried about this. I always do 'cp Image /dev/PS0',
>and it works fine. Everybody else uses dd. Can someone tell me
>if I'm doing a *very bad* thing ?
cp works fine, but dd was a /lot/ faster with the old floppy driver that
didn't do track buffering. With the current kernel there's not too much
difference between cp and dd, so you can safely use cp now. (Another
reason I use dd in the kernel Makefile is that some old version of GNU
cp "optimized" the copying by not copying zeros (doing a lseek() over
them instead), which works fine on regular files but breaks on special
files like /dev/PS0. Newer cp's don't have this problem)
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: FIFO's
Keywords: A
Message-ID: <1992Jun30.172600.7661@klaava.Helsinki.FI>
Date: 30 Jun 92 17:26:00 GMT
References: <1992Jun30.154421.20029@ucc.su.OZ.AU>
Organization: University of Helsinki
Lines: 21
In article <1992Jun30.154421.20029@ucc.su.OZ.AU> chrisa@extro.ucc.su.OZ.AU (C. G. Albone) writes:
>Hello *
> What is the latest news on FIFO's? Will there be anything
>near ready for release soon?
I got the patches for named pipes from Paul Hargrove, and while I had
some problems with them (you don't want to know), they are now corrected
and seem to work well in my system. I edited them a bit while searching
for the bug, and I haven't really tested them extensively yet, but at
least they should be in the next release. Right now I'm wondering if I
should make a small patch3 that contains mainly that code and some other
minor fixes, or if I should do the alpha extended filesystem patches
first and try to have 0.96b.pl3 support 4TB fs's and long filenames. It
depends on how the ext-fs patches seem.
Assuming the extended filesystem poses no problems, next week should see
a patch that contains them. After that I'll do the DOS fs patches, and
then I'll probably relax a bit and let people work on the new file
systems to find the bugs. We'll see.
Linus
================================
================================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Patches.. (Was re: <none>)
Message-ID: <1992Jun30.210216.12584@klaava.Helsinki.FI>
Date: 30 Jun 92 21:02:16 GMT
References: <1992Jun30.004140.4543@athena.mit.edu> <CORYWEST.92Jun29215604@rio-grande.rice.edu> <1992Jun30.155048.6563@spuddy.uucp>
Organization: University of Helsinki
Lines: 98
In article <1992Jun30.155048.6563@spuddy.uucp> sweh@spuddy.uucp (Stephen Harris) writes:
>
>However, the problem I forsee with projects like this is a lack of
>(i) co-oridnation
>(ii) quality control
Indeed. I try to keep both these going, but it's not exactly easy. The
biggest problems are (a) features that I haven't used too much before
(and thus don't know the exact semantics), (b) hardware peculiarities or
simply hardware I don't have and finally (c) lack of infinite time and
energy. (a) can result in some weird behaviour (like the pty change in
pl2) while (b) results in code I cannot check. (c) is pretty obvious :)
>I'm sure Linus would hate to have to rigorously check EVERY patch that
>goes to him - he'd never have any time to program himself :-)
Most of the patches I get and apply are quite thoroughly checked by me
both by reading the actual cdiffs (which is why I often insist on diffs
instead of new files even if the diff is about the same size) and by
then reading and possibly modifying the code. And several patches
either aren't used or are heavily modified.
The biggest patch that I didn't check is the SCSI drivers: it's
essentially useless to wade through code when you can't change it anyway
for being afraid you break something. It shows pretty well in the
sources too: the scsi drivers look quite different from the rest of the
kernel.
Most other patches have gone through pretty rigorous checking: some have
looked definitely different after I have had my way with them. So, if
you do kernel patches, and want them included in a future release, here
are a few points that can make it go faster:
- mail it to me. If it's more than a couple of hundred of lines of
compressed uuencoded patches, you had better talk with me about it
first: patching more than that is definitely not something I like to do
without a very good reason. I won't fetch patches from ftp-sites unless
there is some good reason for it.
- do it in small separate parts. If you fix a lot of things, send
several small patches rather than one big one. That way I can (a) more
easily see what the patch does, and (b) select and edit the patches more
easily.
- follow the same programming style as the rest of the kernel (not
counting the scsi drivers). That means tabs and the normal linux brace
placing. If I like the look of the code, it's easier for me to follow
and I'm definitely not above disliking a patch just for visual reasons.
Even when the above holds true, I might not patch it in for several
reasons:
- If I don't like the way something is implemented, I usually skip it
completely, or then I might write my own version if I find it an
interesting and useful patch. Not liking it can be due to several
reasons: bad special case checking, bad coding style, weird and long
functions and uncomprehensible algorithms. Or any number of things.
- hardware reasons: if I don't have the hardware I'm less likely to
patch it in. The scsi drivers went in because they were obviously
needed (and didn't clutter the rest of the kernel). This is definitely
why I still haven't looked at the ethernet patches nor the bus-mouse
driver: both might be vital to some, but...
- if I'm busy with other things or the patch doesn't go in cleanly due
to other patches, I might just forget about it and hope the patcher
makes a new version for the next release. Some patches have had to wait
for several releases until I implemented them.
- simply because I don't feel it's important enough. Bug-fixes and
important fundamental new features definitely get priority, as well as
some things I simply consider interesting.
- they don't fit well with something I've been thinking of doing. This
goes for the VM86 patch: it's an interesting concept, but to make it go
in cleanly I'll have to re-write the mm a bit first. The current mm
patches for VM86 are something of a hack, and might make it difficult to
correct the mm later. And while VM86 is good, a clean mm is more
important right now.
The result of all this is that if you want a patch to go in, you have to
(a) tell me about it (b) make me understand that it's really nifty (the
itimers patch went in the day I noticed xneko wanted them :-) (c) do it
cleanly: linux is a hackers kernel, but that definitely doesn't mean
ugly hacks are encouraged (d) tell me about it some more. If you feel
something needs bigger changes (like the msdos filesystem needing 32-bit
inode numbers), it's a better bet to mail me and ask about it, and I
might do it myself just because I feel better about it after that.
Also note that the fact that I don't use it doesn't really matter: some
patches are quite useable just as patches. Or as complete systems from
somebody else than me: if somebody thinks a linux system with
"unofficial" patches would be useful, it's certainly a good idea.
Several packages have come with kernel patches just because the standard
kernel didn't support them (the original X and ps095 both had kernel
patches in the distribution to add the necessary features.)
Linus
===========================
===========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Logitech mice
Message-ID: <1992Jul2.225253.7764@klaava.Helsinki.FI>
Date: 2 Jul 92 22:52:53 GMT
References: <3300@sicsun.epfl.ch>
Organization: University of Helsinki
Lines: 31
In article <3300@sicsun.epfl.ch> lecom@slhp1.epfl.ch (Claude Lecommandeur) writes:
>
> For all the people (like me) who lost hope of making their logitech
>mice, Apply right now the patch2 to 0.96b. It works perfertly. Thanks to
>Linux.
I'm happy that the second patch does indeed seem to correct the problems
(or at least most of them) people had with some mice. I just wanted to
say that there is a pretty bad bug in patch2, which happily is easy to
correct (even without an additional patch).
The problem occurs if you try to open a tty special file that doesn't
have any device connected to it: ie if you try to open /dev/ttyp4 and
the kernel has been compiled for just 4 pty devices (ttyp0-ttyp3). The
result of the open is an instant reboot.
The above holds true for all other "undefined" tty devices as well: if
you have created a nonexistent /dev/tty9 (the ninth virtual console when
only 8 are defined by the kernel) and try to open it, things don't work
too well. Most people haven't defined any extra special devices, but
those who have should remove them.
The problem is in the tty_ioctl.c file: in the functions
flush_[in|out]put() which don't check that the queue's actually exist
sufficiently. I have corrected it already, and patch3 (probably out
Saturday) will contain this fix as well as some other new features (the
alpha code of the extfs, named pipes, corrected console handling etc).
In the meantime everybody who uses patch2 should make sure they have no
bad tty special files (major = 4) in their /dev directory.
Linus
=============================
=============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: To Linus, Lions book?
Message-ID: <1992Jul3.113506.20524@klaava.Helsinki.FI>
Date: 3 Jul 92 11:35:06 GMT
References: <1992Jul3.090424.15207@athena.mit.edu>
Organization: University of Helsinki
Lines: 96
In article <1992Jul3.090424.15207@athena.mit.edu> J.Jagger@sheffield-city-poly.ac.uk writes:
>
>How did you get all your now how to create Linux?
>Was hands on learning, which books/mags/articles/code
>did you read? Go on Linus, give us a potted life history :-)
Heh. I can't let these ego-building posts go by, so I'll have to answer
it.
Linux started for several different reasons: originally just to learn
the 386, and for this the book "Programming the 80386" by Crawford and
Gelsinger is a must. At least I haven't found anything better (although
admittedly bookstores in Finland probably don't have the plethora of
books available over in the US etc).
The 386 book info has been used for all the 386 details: the lowest
level of the task-switching code, memory manager, floating point
emulations etc. It doesn't even mention the AT hardware, so for device
drivers you'll need more info, but it does contain everything on the
386/387 chips (even if it's a bit hard to read: read it through several
times before starting to look into details).
The device drivers have been written mostly by trial and error: I
haven't found a single good source of info on the standard AT hardware.
Helpful sources have been (a) the AT Technical Reference Manual (notably
the BIOS listing) (b) actual data-sheets for the 8250 etc chips used in
the AT hardware (c) other sources (mach drivers and to a lesser extent
minix drivers) (d) various books like "IBM Microcomputers: a programmers
manual", "The PC Sourcebook" etc.
Even though there are a lot of books on the AT hardware, none of them
seem to approach the information content of the 80386 books. I can't
recommend any of the sources I've used, and the best bet is probably to
have a lot of books and hope they together cover most of it.
Then there is naturally the hardware-independent parts of the kernel:
general filesystem/process/memory management. The two books I
originally used were "The Design of the Unix Operating System" by Bach,
and "OS Design and Implementation" by Tanenbaum. Tanenbaum's book
should be read a couple of times: ignore the details (especially about
minix), but get the general picture clear. The Bach book has a few nice
algorithms in it, and I'd suggest reading them too: many of the actual
ideas on how something could be implemented came from that.
Still, OS design is mostly common sense: it doesn't need complicated
algorithms like a compiler does or similar. A lot of thought, careful
programming and some good decisions. And unix is a very simple OS
really: I first came in contact with it 2 years ago when I did the
"C-kieli ja unix ohjelmointiymp{rist|" course in the fall of -90. By
early -91 I had bought a PC, and linux v0.01 was ready in August -91.
That wouldn't have been possible with some other systems I could mention
(VMS.. arghh).
The most difficult parts are:
- device drivers: you can go crazy trying to find why something doesn't
work on some machines (especially if you can't even test it out).
- filesystem: trying to make it clean and well designed, as well as
getting rid of all race conditions. The current linux vfs layer seems
to work well enough, but my original design wasn't too good. Rewriting
big parts isn't fun when something works.
The kernel proper is pretty simple in fact, although you have to keep
track of a lot of things. The memory manager has also survived pretty
well all the changes, and although I'll have to change it to use
different page directories for different processes some day it will
probably look pretty similar even after that.
>Also could you mail me a few lines, grouping the source code
>files into chunks. I.e., which files make up the lowest most
>basic layer of the OS 'onion', which ones make up the next layer?
>This would make it lot easirt to peruse the code in an orderly fashion
>so I can try to understand it.
Hmm. To get a good general idea of the different pieces, I'd suggest
reading linux/*/*.c - all the memory management sources, the normal
kernel sources and the vfs routines. They are pretty modular: you can
generally understant linux/fs/*.c without having to understand the
kernel and vice versa (for a general picture, that is. For the details
you usually have to read it all).
The linux device drivers (linux/kernel/chr_drv and linux/kernel/blk_drv)
are a pain to read: they don't actually give you any more info on the
kernel itself, so reading them is only needed if you really want to know
how a block is loaded into memory etc. Similarly for the math-emulator
(linux/kernel/math).
The special filesystems (linux/fs/minix and now linux/fs/ext) can be
read if you are interested in the actual lay-out of the disk, or if you
want to see how some of the fs races are handled. Note that most
race-conditions are handled directly by the buffer-cache routines or the
vfs layer, but some races are inherent to the actual fs implementation
(renaming a file etc).
Linus
=============================
=============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Speed of GCC
Message-ID: <1992Jul3.180739.26258@klaava.Helsinki.FI>
Date: 3 Jul 92 18:07:39 GMT
References: <1992Jul3.133741.18573@tc.cornell.edu>
Organization: University of Helsinki
Lines: 31
In article <1992Jul3.133741.18573@tc.cornell.edu> elan@tasha.cheme.cornell.edu (Elan Feingold) writes:
>
>This may be a stupid question, but I'm wondering why GCC is so Slooow...
>All my MSDOS (yech) compilers (i.e. Borland) compile things very much
>quicker. I could understand a RISC compiler being much slower, as it
>has to handle many more things, but under 386 LINUX I would think it
>should be faster...
There are several reasons for gcc being slow under linux:
- it's big: if you haven't got much memory (4M or less), it generally
swaps, and doesn't fit in the buffer cache. With 8MB or more, gcc is
pretty ok speedwise.
- it's good: it does a lot of things that many DOS compilers don't do.
- as all GNU software, it has been mostly developed on big and fast
machines: size and speed of the compiler has been very much a
secondary issue.
- it's general: it has been written to work on several different
platforms and produce code for many different processors. As with
most problems, that automatically means it's slower than something
that is specially written for one architecture.
Also, IO etc can in many cases be faster under DOS than under linux: a
single-tasking system can make shortcuts that aren't possible under a
"real" OS. (Not that djgpp under DOS is faster than gcc under linux:
but that's because djgpp has to do a lot of ugly things to work at all).
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Compiling 0.96b kernel with gcc 2.2.2
Message-ID: <1992Jul3.212912.29760@klaava.Helsinki.FI>
Date: 3 Jul 92 21:29:12 GMT
References: <23300@castle.ed.ac.uk> <23334@castle.ed.ac.uk> <1992Jul3.191439.12493@nwnexus.WA.COM>
Organization: University of Helsinki
Lines: 30
In article <1992Jul3.191439.12493@nwnexus.WA.COM> vince@halcyon.com (Vince Skahan) writes:
> [ deleted ]
>/dev/hda1: Function not implemented
>Couldn't stat root device.
>make: *** [Image] Error 1
>
>
>....the (sadly) interesting thing is that if I use the 2.2.2 compiler
> to make the shellutils, textutils, etc, there are certain
> of those programs that, when executed, give the 'Function not
> implemented' message listed above...
Well, the reason is very simple: the gcc-2.2.2 library uses the new
stat() system call, which isn't (surprise surprise) implemented in
kernel versions 0.96a.pl3 and below. Thus the very logical "Function
not implemented". The gcc docs do mention the fact that you must be
running 0.96a.pl4 or above.
The solution is (a) to get the 0.96b image from the ftp sites and use
that while compiling the new kernel (or utilities) or (b) to use an
older gcc while running the old kernels. (a) is preferable.
If somebody missed the discussion, the reason the stat() system call was
changed was to make a new 'struct stat' available that supports 32-bit
inode numbers as well as the st_blocks fields (although they are
actually 0 in linux-0.96b.pl2 and below). And while all old binaries
work fine under the new kernel, newly compiled binaries automatically
use the new stat() system call.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Anyone collecting bugs out there?
Message-ID: <1992Jul4.202540.21929@klaava.Helsinki.FI>
Date: 4 Jul 92 20:25:40 GMT
References: <1992Jul4.184224.24930@dg-rtp.dg.com>
Organization: University of Helsinki
Lines: 28
In article <1992Jul4.184224.24930@dg-rtp.dg.com> welshm@mirage.rtp.dg.com (Matt Welsh) writes:
>I've got a question-- is there anyone who's been collecting the many
>various bug reports for Linux posted to this group?
>I was just thinking, it might be a nice idea to have someone in charge
>of getting bug reports (either by e-mail directly for from postings
>to this group), compiling them into one big report (that could be
>kept updated) so that new (as well as experienced) Linux users could
>grab a copy of the most recent bug report and see if the problems they're
>having are true verified "bugs" in Linux or have workarounds (and are
>due to different setups, i.e using the wrong version of GCC with
>a certain patchlevel).
This was tried a while back: there was a whopping bug-file available at
tsx-11.mit.edu at some time. The problem was that most of the
bugsreports were very quickly outdated (and, as you say, due to
installation problems in some cases). I doubt the bug-list ever got
very useful, even though the idea was good. As with many things, the
speed of linux development makes documentation difficult.
Most bugs reported on the net are (a) either hardware-related and thus
very difficult to check out or (b) the bug-report is followed by a fix,
and thus keeping the report is not very practical. The best way to
avoid bugs is generally to have the newest kernel (even though some bugs
are introduced with new versions.. on the whole things get better with
higher version numbers). I hope that 0.96c (ie 0.96b.pl3 - out later
today) will fix all known non-hardware bugs. Knock wood.
Linus
=============================
=============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 0.96c out
Keywords: kernel release
Message-ID: <1992Jul4.232540.25763@klaava.Helsinki.FI>
Date: 4 Jul 92 23:25:40 GMT
Organization: University of Helsinki
Lines: 41
The latest kernel version is 0.96c: the binary and sources can be found
on banjo.concert.net: pub/Linux/Linus as usual. I haven't made the
cdiffs yet, and I'll upload those tomorrow (at the same time I'll put it
on the other sites as well).
0.96c is actually what I called patch3 earlier this week, but as the new
features were pretty big and the cdiff's are probably going to be bigger
than the normal patches, I decided I might as well make it a totally new
minor release and make a bootimage and complete source available.
0.96c contains:
- bugfixes (tty, console driver, pty's, sockets)
- fifo's (names pipes - Paul Hargrove & editing by me)
- the alpha extended filesystem (Remy Card)
- st_blocks implemented (ie du, ls give reasonable if not exact values
for disk-space used)
- Makefile cleanups and warnings at compile-time removed
Note that while the extended filesystem code is there, and this kernel
successfully mounts and uses the new filesystem (with long filenames and
>64MB partitions), it's still under testing: I haven't made the mkefs
program available, and the extended filesystem features shouldn't be
used for other than testing right now.
Some of the changes are just cleanups: most of the warnings when
compiling the new kernel should be gone (not counting the scsi code
which is still the old non-cleaned-up version), and the make'ing of the
kernel is more logical now.
The bugfixes include the corrected console.c driver, the socket
corrections (without which X sometimes locks up), some pty semantics
corrections (although I'm still not certain it's correct) and some
editing in the general tty driver (including fixing the bug introduced
in 0.96b.pl2 that caused a reboot with uninitialized tty devices).
While the extended filesystem support isn't "official" yet, I can
happily report that my limited testing hasn't found any problems with
long filenames etc. It still needs a fsck program, but 1.0 looks like a
real possibility soon.
Linus
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.96c out
Keywords: kernel release
Message-ID: <1992Jul5.074120.3661@klaava.Helsinki.FI>
Date: 5 Jul 92 07:41:20 GMT
References: <1992Jul4.232540.25763@klaava.Helsinki.FI>
Organization: University of Helsinki
Lines: 18
Earlier I wrote:
>The latest kernel version is 0.96c: the binary and sources can be found
>on banjo.concert.net: pub/Linux/Linus as usual.
I have had one report that 0.96c won't compile with an older gcc even
though 0.96b does ok. The solution is to get gcc-2.2.2: that's what I
use (the problem was the console.c file, specifically the asm statement
in scrup() - some gcc versions seem not to be able to keep enough
registers free for it).
If you are unwilling to get the new compiler, you might have to stay
with 0.96b.pl2 (or just get the new binary). Also note that if somebody
uses the extended-fs features, you'd want to recompile most programs
with 2.2.2 anyway: that way they use the correct vfs readdir() function
(reading a directory directly won't work on the ext-fs) and the new
stat() functions.
Linus
=============================
=============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Bug in 96c!
Message-ID: <1992Jul8.090104.29648@klaava.Helsinki.FI>
Date: 8 Jul 92 09:01:04 GMT
References: <13d04pINN8fo@matt.ksu.ksu.edu>
Organization: University of Helsinki
Lines: 23
In article <13d04pINN8fo@matt.ksu.ksu.edu> probreak@matt.ksu.ksu.edu (James Michael Chacon) writes:
>Just an annoying bug I found with 96c. When I run X and then exit from it, the
>system hangs. Not completely, the keyboard comes back, but typing on it does
>nothing. (i.e. characters appear, but no response from linux)
Yes, it's a bug, but it's already corrected in my version: the weekly
patch (probably out this weekend) will correct it. The problem is the
TIOCCONS ioctl: if you use "xterm -C" to get console output redirected,
the redirection doesn't stop correctly when the pty is closed. What you
are seeing is a linux system with the output redirected to a pty that is
no longer in use.
The reason it showed up in 0.96c is that the pty usage-counts changed a
bit in order for the pty's to have the correct behaviour when one end is
closed: but I forgot about redirection which depended on the old
behaviour. The bug isn't too bad: the system doesn't actually crash,
and if you wait 30 secs, update does it's job and you can reboot safely.
Or you can avoid it altogether by not using "-C" with 0.96c for now.
(patch1 will mostly be internal changes for the irq-lines, although
there are a few patches in there and the above fix).
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: ftruncate bug
Message-ID: <1992Jul8.175040.10667@klaava.Helsinki.FI>
Date: 8 Jul 92 17:50:40 GMT
Organization: University of Helsinki
Lines: 32
There is a typo in fs/open.c: sys_ftruncate() where the
write-permissions are checked from the f_flags entry instead of the
f_mode structure-entry. It results in ftruncate() failing on files
opened with O_RWONLY. This resulted in the weird behaviour for the GNU
'cp' command when it's compiled with all the new libraries etc.
The problem shows itself when GNU cp copies a file that ends with
zero's, and cp tries to make a hole in the file. GNU cp writes one byte
past the end, and then uses ftruncate() to get the right file-length. On
0.96c and earlier this results in EACCES, and cp reports someting like
cp: Permission denied
and exits. The file is mostly good: it's just one byte too long and
doesn't get the right permissions (as cp gives up before doing the
chmod). As this only happens with files that have zero's at the end,
you don't usually notice it even if you have a new version of cp.
The fix is easy: either wait for patch1 (still out this weekend), or fix
it yourself. I haven't made patches yet, but it looks something like
this (line 94 in fs/open.c, function sys_ftruncate()):
if (S_ISDIR(inode->i_mode) || !(file->f_flags & 2))
return -EACCES;
Just change the f_flags to f_mode, and everything is well.
Also note that this bug doesn't matter for older binaries: ftruncate is
a pretty new system call in linux, so few binaries actually use it. It
also happens to work correctly if the file is opened with O_RDWR.
Linus
==================
==================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Disk cacheing
Message-ID: <1992Jul10.091409.20803@klaava.Helsinki.FI>
Date: 10 Jul 92 09:14:09 GMT
Organization: University of Helsinki
Lines: 19
Oh, boy. >10 messages today about the fs cache - a totally unnecessary
waste of space. This is my $0.02:
- the buffer cache stays the same.
That's it. If somebody wants to get rid of caching, change the source
and see if you really want it to stay that way. I'm not going to remove
cacheing even if I get patches, but maybe you can make a non-cache
release on your own.
If somebody wants more frequent sync's: the update program is 10 lines
long, and changing it to update every other second or so would certainly
effectively disable the write-cache. Or add the automatic sync to bash:
"PROMPTCMD=sync" or similar. Or use DOS.
I don't know where people get their numbers, but I do know that gcc runs
at least twice as fast if you have a decent cache. End of discussion.
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Patch1 to 0.96c out
Keywords: 0.96c patch
Message-ID: <1992Jul11.204011.21601@klaava.Helsinki.FI>
Date: 11 Jul 92 20:40:11 GMT
Organization: University of Helsinki
Lines: 62
[ I already sent this to the normal mailing-list, so you can skip this
if you already got it by mail ]
I have sent off my first patch to 0.96c: as usual it's available
directly from banjo.concert.net while nic.funet.fi and tsx-11.mit.edu
might take a day or two to put it into the right directories.
linux-0.96c.patch1 contains more changes than I originally envisioned: I
changed the IRQ routines and the serial code to be easier and cleaner
(and hopefully more efficient) and I thought that would be it. I was
wrong.
I got several patches (and one bug-report) again, and while I haven't
had time to check them all, some of them are in. Fixes:
- Remy Cards correction to the out-of-space problem with the extended
fs is here. Most people using the ext-fs might already have applied
this patch, in which case you might have problems patching.
- my ftruncate() fix is here. Again, if you already did the trivial
patch by hand, you'll get errors when patching.
- almesber's implementation of read-only filesystems is here (after
editing by yours truly). The mount() system call now accepts a flags
integer as well as a pointer to some arbitraty data in user space for
some special mount() calls. The general flags allow (a) read-only
mounting, (b) disabling of suid executables (c) disabling of device
special files and (d) total disabling of executables on a per-filesystem
basis. The filesystem specific mount() info isn't currently used by any
fs, but can be used to specify additional information that depends on a
special fs type (a password or similar would be possible..)
- the rename() system call had a bug in that it allowed moving over a
directory: I think the code to handle this was lost in the vfs editing,
and although the GNU mv utility checked it, a malicious (or just
unsuspecting) program can destroy the fs using this. Thanks for the
bug-report: it was very easy to add once I saw the problem.
- support for vesa-standard svga cards in setup.S. I'm unable to test
this, but my svga card still works after the patch, so I left it in in
the hope that it doesn't break for anybody else.
- various minor editing by me, or minor patches sent in by others.
The full cdiff is almost 50kB compressed, so this is a bigger-than-usual
patch. Hope there are no problems. People who are using the new SCSI
drivers might have problems with my changes to the SCSI irq-setup
changes, so be careful (actually using the original sources might be a
good idea, and then upgrading again). I hope to get the new SCSI
drivers into the kernel soon (definitely in time for 0.98).
I'd be interested to hear comments on serial line performance, bugs,
features, etc. As usual, I'm hoping this release won't contain any new
bugs while fixing all the old ones, but I guess that's likely to happen
right after the first winter olympics in Hell.
Linus
PS. Maybe nobody noticed, but I actually never made the patches to
0.96c available. As nobody has complained, I assume everybody just got
the complete kernel sources and used that. Unless somebody actually
asks for them, I don't think there is any point in making them any more.
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Floppies (was Re: File system issues!)
Message-ID: <1992Jul12.104841.2039@klaava.Helsinki.FI>
Date: 12 Jul 92 10:48:41 GMT
References: <PSHUANG.92Jul9232005@m4-035-10.mit.edu> <1992Jul10.140622.4927@email.tuwien.ac.at> <1992Jul10.164650.2229@rs6000.cmp.ilstu.edu>
Organization: University of Helsinki
Lines: 44
In article <1992Jul10.164650.2229@rs6000.cmp.ilstu.edu> jliddle@rs6000.cmp.ilstu.edu (Jean Liddle) writes:
>
>Doesn't the autodetect feature on fd0, fd1 already detect when a floppy has
>been changed. I know under mtools I often get a message to the effect that
>"the floppy is undefined because it has been changed". Mtools does not
>leave the motor running. Perhaps this feature could be incorporated into
>the standard linux floppy read/writes, if it hasn't already.
Floppy change detection has been there since the beginning of the floppy
driver (linux-0.11, I think. Note that the harddisk driver was there
from the beginning), but only the autodetect floppies actually say
something about it (as they have to re-detect the media, and the
debugging info was a good way to make sure it detected them correctly).
The main problem has been (a) some hardware simply doesn't send the
correct floppy-changed signal (notably old drives: at least some 360kB
5.25" drives) (b) some bugs in the early code (linux in fact thought a
disk had been changed even when it hadn't in some circumstances).
(b) should be corrected now (thanks to almesber: the floppy-changed
signal is reset by seeking a bit), while (a) is still a problem on some
(very few) drives.
[ Note: the floppy-change signal is checked only when opening and
mounting a floppy: if you change the floppy while the device is open or
mounted you are in for some surprises ]
>On another note, has anyone considered making 1.72 MB disks a la fdformat
>for DOS readable under Linux?
Check out the floppy ioctl()'s: along with the auto-detecting, almesber
added support for forcing the floppy to use a user-defined setup, which
can include these kinds of user-defined sizes (but note that the
track-buffer is used only if there are <= 18 sectors per track, so you
get bad performance with nonstandard formats beyond that).
That said, the floppy driver is a mess. It's been changed and hacked on
like the other drivers, but as it's a pain in the *** (and very boring)
to program floppies, nobody has really cleaned it up. It's gotten
better performance and features over time, but it's one of the pieces
that should be taken out and shot. But I'm not going to, as writing a
new one is just too depressing.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Device names (was Re: ttys2 not responding)
Message-ID: <1992Jul12.181359.6939@klaava.Helsinki.FI>
Date: 12 Jul 92 18:13:59 GMT
References: <710808938.F00117@remote.halcyon.com>
Organization: University of Helsinki
Lines: 54
In article <710808938.F00117@remote.halcyon.com> Rob.Levin@f217.n3802.z1.fidonet.org (Rob Levin) writes:
>
>Well, if we're going to be consistent, shouldn't we *then* change the
>*local* consoles to tty[0-7]? Otherwise, we have tty[1-8], but
>ttys[0-3], which isn't terribly consistent....
If you don't have tty0, your installation is lacking: tty0-8 are
perfectly valid console devices. BUT tty0 is special: it's not limited
to just one of the virtual consoles, but is always the current one.
tty0 should be used if you have some important message that you want to
make /sure/ is printed on the console regardless of which VC is in use
(the same way kernel messages are always printed to the current console)
If you don't have the tty0 device, you should create it with
# mknod /dev/tty0 c 4 0
and also make the /dev/console the same device (either by linking or
making a similar special file for it).
>Well, far be it from me to splash water, doesn't the existence of
>/dev/fd0 and /dev/fd1 sort of render all this complication *moot*? Are
>there any situations where autodetect could *not* be used successfully?
>If not, are there any situations where one would *want* to use the more
>cumbersome forms simply for consistency purposes?
There are some circumstances where the auto-detect floppies cannot be
used: the most obvious of these is when formatting disks, as there is no
way for the driver to auto-detect an unformatted floppy.
Also, if somebody wants to make his own floppy formats and code them
into the kernel (and it's not too hard to do), the new floppy naming
scheme will hopefully give him/her obvious names for the non-standard
devices even though the auto-detect code doesn't recognize them. Having
a fairly obvious naming standard for these kinds of devices shouldn't
hurt.
>P.S. Shouldn't we consider starting our hard disk partitions with
>/dev/hda0...? If not, why not...? ;-)
Actually, the current /dev/hda is a kind of /dev/hda0 (check the minor
device numbers) - but in order to make doubly sure that nobody confuses
the device with a normal partition (/dev/hda is the whole first HD), I
decided on the current numbering when I finally chucked the minix naming
over-board. I haven't regretted it: while there were no end of problems
with the old names, everybody seems to understand the new naming
conventions.
[ For those that don't remember the old minix naming mess: /dev/hd0 was
the current /dev/hda, /dev/hd1 was /dev/hda1... /dev/hd5 was /dev/hdb,
/dev/hd6 was /dev/hdb1. The numbers were directly linked with the minix
minor numbers, and resulted in major confusion ]
Linux
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: selecting irq's
Message-ID: <1992Jul12.200240.8864@klaava.Helsinki.FI>
Date: 12 Jul 92 20:02:40 GMT
References: <1992Jul11.043103.28342@athena.mit.edu>
Organization: University of Helsinki
Lines: 38
In article <1992Jul11.043103.28342@athena.mit.edu> Brad.Midgley@m.cc.utah.edu writes:
>
>How do I tell linux about the strange irq's which my serial ports above
>2 use? Can anything go wrong if I don't tell it these irq numbers but
>don't use those ports either?
Even if the ports have weird IRQ setups, that shouldn't hurt if you
don't use them (unless they are /truly/ weird and interfere with the
harddisk or something, but that's not very probable (understatement of
the year)).
>I haven't looked at the source yet, but I assume that linux will not let
>you open two serial ports which SHARE the same irq, but once you let it
>know that, say, port 3 uses irq 2, it will let you open both at the same
>time, no?
Yes, you can have as many serial ports open as you wish, as long as they
don't share IRQ's. 0.96c + patch1 should be truly free about the serial
IRQ's: it should be possible to set them up to anything as long as it
doesn't interfere with anything else. Of course, I have used the
"Linus' Extended Testing System" (pat.pend.) on all this, so it's
(almost) guaranteed to work (*).
Note that earlier versions (a) required kernel patches to use any
non-standard IRQ's, or (b) only supported a limited number of different
serial IRQ's (0.96b.pl2 handled irq2,3,4 and 5). 0.96c+patch1 should be
dynamically configurable to use /any/ free IRQ line (and port address).
Linus
(*) "Linus' Extended ...", (ie LETS) is a revolutionary concept: you
write the code, pray to God it works, and if God doesn't contradict you,
you release it as an "Official Patch" (tm) after which you pray none of
the beta-testers contradict you either. It doesn't always work, but it
sure cuts down on the time needed for testing. (**)
(**) No, I'm not totally serious. Ha Ha. I've just been on the lines
too much. I'm much better now. Really.
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: race condition if minixfs??
Message-ID: <1992Jul13.103705.25008@klaava.Helsinki.FI>
Date: 13 Jul 92 10:37:05 GMT
References: <1992Jul12.041727.24125@news.Hawaii.Edu>
Organization: University of Helsinki
Lines: 30
In article <1992Jul12.041727.24125@news.Hawaii.Edu> oles@spectra (Shawn Oles) writes:
>
>I can't figure out how the following race condition(?) is avoided in
>Linux's <minix file system>:
>
>What happens if two processes, (A & B), are trying to find a free block
>on the same device. If process A interupts at <interupt T> and B
>comes into "minix_new_block", aren't they both going to grap the same
>block, which would result in a system panic on the set_bit ?
Processes cannot be interrupted by another process (only a hardware
interrupt - and they don't switch tasks) when they are running in kernel
mode unless they actually sleep. And as no interrupt calls
minix_new_block, there is no need to check for races.
Things that can sleep and thus be interrupted by another process:
Obvious:
scedule()
[un]interruptble_sleep_on()
any IO except printk()
Not so obvious:
accessing user-space memory
(remember: it might swapped out or not be loaded)
As minix_new_block doesn't do any of the above (the buffers that it
searches are already loaded), it doesn't sleep -> no other process runs
during that time.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Disk cacheing
Message-ID: <1992Jul13.101550.24190@klaava.Helsinki.FI>
Date: 13 Jul 92 10:15:50 GMT
References: <1992Jul10.091409.20803@klaava.Helsinki.FI> <1992Jul12.071717.20019@cheshire.oxy.edu>
Organization: University of Helsinki
Lines: 22
In article <1992Jul12.071717.20019@cheshire.oxy.edu> rafetmad@cheshire.oxy.edu (David Giller) writes:
>
>Agreed. But... Could we please have a second thought about at least
>upgrading the existing buffer cache?
Oh, I didn't mean I wouldn't be open to changing implementation details,
algorithms etc. Even to disable write-caching for one partition or so
is no problem: add a flag to the mount() call (easy in 0.96c.pl1) that
is the equvalent of O_SYNC for a file (which isn't implemented either).
It will take some code to actually implement it, but probably not too
much (and note that it wouldn't be default, but people might do
something like "mount -t ext /dev/hdb1 /usr/spool sync" to get it to
work).
What I just reacted against were the big number of posts that wanted "a
better DOS than DOS" or something similar. Frankly, as long as the
arguments are on that level, I essentially ignore them. That doesn't
mean I don't understand arguments like "I'd like to run linux as a
newsfeed, and write-through would help". Although actual patches are an
even more convincing argument :-).
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Splitting the comp.os.linux group
Message-ID: <1992Jul13.213830.13210@klaava.Helsinki.FI>
Date: 13 Jul 92 21:38:30 GMT
References: <1992Jul13.093121.27993@wega.rz.uni-ulm.de> <1992Jul13.150727.7923@cl.cam.ac.uk>
Organization: University of Helsinki
Lines: 45
In article <1992Jul13.150727.7923@cl.cam.ac.uk> qs101@cl.cam.ac.uk (Quentin Stafford-Fraser) writes:
> [ comp.os.linux subgrouping ]
>|> Is there anyone out there of the same opinion?
>
>I think almost everyone is - There have been several postings to this
>effect, with slight variations on the names of suggested groups, and I
>have seen no dissenters. Any split would be an improvement - let's get
>on with it. Who do we need to persuade to actually get the thing done?
No, everybody does not think this is a good idea: admittedly the traffic
on comp.os.linux has been high and varied, but I don't think we really
need more newsgroups. I don't really think the traffic is big enough to
support several groups, and I think the right solution is to try to find
a threading newsreader if at all possible (like trn).
Most of the discussion is (a) how/where to get linux and beginners
questions: this shouldn't require a newsgroup of it's own but just
better docs etc. (Not that I'm about to write them :-) (b) general
discussion that would have to be in comp.os.linux anyway. The number of
questions relating to a limited area (like X11) isn't really that high,
and it has dropped (in the case of X) lately, or so I think.
One argument for newsgroups has been that there are mailing-lists that
people feel would be nicer to have as a newsgroup: but the mailing-lists
and the newsgroup really have different uses, and should be separate
(for one thing having a mailing-list for a well-defined area like the
standards-list cuts down the noise-level a bit when compared to a
newsgroup).
A newsgroup like comp.os.linux.beginners may sound like a good idea, but
I doubt it would actually work: people would crosspost to the "real"
group anyway, and while it's sometimes irritating to see the same
questions over and over, I don't think we can get rid of them. (Well,
other than by making everybody afraid of posting because they get
flamed, which I don't feel is a good idea: some of the replies have been
a bit acerbic, and I've gotten a few mails directly to me, because
people actually don't like posting due to that. Not good.)
As to something like comp.os.linux.X11 - the idea is to get X working so
well under linux that no such group should be needed: the normal X group
should answer most questions. Hopefully the same goes for things like
"rm ./-i" that should really be in comp.unix.wizards (heh. Try it some
time :-)
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Badblocks revisited (**sigh**)
Message-ID: <1992Jul14.105705.7189@klaava.Helsinki.FI>
Date: 14 Jul 92 10:57:05 GMT
References: <1992Jul13.054522.15674@cc.umontreal.ca> <Jul.13.14.46.48.1992.12686@dartagnan.rutgers.edu> <mper.711085997@uipsuxb>
Organization: University of Helsinki
Lines: 12
In article <mper.711085997@uipsuxb> mper@uipsuxb.ps.uiuc.edu (Michael Pereckas) writes:
>
>Is it possible for the read-ahead code to read ahead into some bad
>blocks?
Yes, it's possible. It shouldn't happen when using the device as a
filesystem, but it can happen when doing a fsck or reading from the raw
device. In that case you should be able to ignore the messages: if you
don't feel comfortable with that, you can remove the read-ahead code on
block devices altogether.
Linus
===========================
===========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: [comp.os.linux]: Re: File system issues!
Message-ID: <1992Jul14.112136.7798@klaava.Helsinki.FI>
Date: 14 Jul 92 11:21:36 GMT
References: <9207131519.AA14556@optical.bms.com> <cy7uNB1w165w@ssg.com>
Organization: University of Helsinki
Lines: 40
[ sorry if the attributions are wrong: the included file was a bit messy ]
In article <cy7uNB1w165w@ssg.com> unixsys@ssg.com (Rick Emerson) writes:
> From: davidsen@ariel.crd.GE.COM (william E Davidsen)
>>
>> Perhaps that class of user should be using fsync() to force their data
>> out.
fsync() under linux isn't implemented right now: although a fsync() that
just does a sync() is possible.
>'Splain me why a "fscache -writeback 0" (or something equivalent) is so
>distasteful? Please, let's not debate the pros and cons of write-back
>caching.
Ok, ok, ok. Here is a simple patch (not cdiff, but you can do it by
hand) that essentially implements write-through. I won't put it into
the standard kernel (unless somebody pays me $$$ - anybody? I'm /very/
corruptible.) but you might try it out if you want to..
In the function brelse(), in fs/buffer.c:
void brelse(struct buffer_head * buf)
{
if (!buf)
return;
+ ll_rw_block(WRITE,buf);
wait_on_buffer(buf);
if (!(buf->b_count--))
panic("Trying to free free buffer");
wake_up(&buffer_wait);
}
One line to add, and voila. Magic.
I still like the fsync() and O_SYNC ideas better, but the above is so
simple anybody can try it out. DISCLAIMER: I used my usual rigorous
testing techniques on the above, ie none.
Linus
============================
============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: problems with the new mount(2)
Message-ID: <1992Jul14.105210.6964@klaava.Helsinki.FI>
Date: 14 Jul 92 10:52:10 GMT
References: <1992Jul11.230357.13628@daffy.cs.wisc.edu> <1992Jul13.145414.7357@bernina.ethz.ch> <1992Jul14.053132.910@daffy.cs.wisc.edu>
Organization: University of Helsinki
Lines: 45
Before you flame each other to death, I'd just like to point out that
the kernel interface to mount() and the actual mount() system call can
(and in this case should) be totally different things. I used the new
kernel-level interface because it's simple and relatively clean from a
kernel standpoint, but that does /not/ mean the actual mount() library
function has to conform exactly to the kernel parameters. There is
precedent for this: some system calls (like readdir()) have arguments
that are totally different from the user-level library interface.
The mount() library would probably look something like this (you could
even do bit-twiddling to get the flags to have the same meaning as in
BSD, although I really doubt it's worth it):
#define __LIBRARY__
#include <unistd.h>
#define __NR_sys_mount __NR_mount
static inline _syscall5(int,sys_mount,const char *,device,const char *,dir,
const char *,type,int,flags,void *,data)
int mount(const char * device, const char * dir,
const char * type, void * data)
{
unsigned long flags = 0xC0ED0000; /* magic number */
int result;
if (data) {
flags |= 0xffff & *(long * data);
data += 4;
}
return sys_mount(device,dir,type,flags,data);
}
That way the library interface would be simple and automatically insert
the magic numbers that mean it's using the new format. And to the
person who complained about magic numbers: there is currently only two
magic numbers like this in the kernel - for reboot and mount. Reboot
obviously wants magic numbers (and they shouldn't even be hardcoded into
the library): otherwise it would be easy for root to reboot by accident
in case some user-level program gets confused. And yes, I could have
made a new mount() system call, but there is not really much difference
between that and the current implementation.
Linus
==============================
==============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: FAQ addition: (was Re: Badblocks revisited (**sigh**))
Message-ID: <1992Jul16.220318.15436@klaava.Helsinki.FI>
Date: 16 Jul 92 22:03:18 GMT
References: <9207160920.AA00919@optical.bms.com> <uR5ZNB6w165w@ssg.com>
Organization: University of Helsinki
Lines: 48
In article <uR5ZNB6w165w@ssg.com> unixsys@ssg.com (Rick Emerson) writes:
>u31b3hs@cip-s02.informatik.rwth-aachen.de (Michael Haardt) writes:
>>
>> Linux does not mark bad blocks, so you have to do that. It's not really
>> difficult, it is just that you need MINIX to do the job. Don't yell at
>> me ...
That was true of linux versions 0.10 and below: I think 0.11 already had
a mkfs that did the mapping out of bad blocks (this can be confusing to
minix users: in minix, you use a special program for it, under linux you
just use "mkfs -c" (or "mkfs -l" if you know the bad blocks)).
Linux maps out bad blocks by putting them in a ".badblocks" file in the
root directory (although you can naturally rename this later) that has
inode nr 2. Minix used several small files, as the minix badblocks
program was too stupid to understand about indirection in an inode, so
it created a inode for every 7 bad blocks (minix inodes have 7 direct
pointers in them).
So if you have a .badblocks file, you should be careful not to try to
back it up if you are doing a full system backup: it will result in no
end of read errors (not too surprisingly).
Also note that linux doesn't do bad-block mapping at a device level:
It's done by the filesystem. Mapping bad blocks on a lower level is
complicated, and often not worth it (as most new controllers do it in
hardware).
> You
> must
> be
> joking!
No, this was standard practice with the early versions of linux. I
hadn't written a mkfs or a fsck, so you actually needed minix to set
things up. Happily, this is no longer true, and hasn't been for about 8
months or so.
>Install another OS to fix this one? (Yes, yes, yes, I know Linux is
>descended from Minix)
Actually, "descended" is too strong a word: I just used minix as the
platform I wrote it on, and that has made its mark mostly on the
original filesystem layout. Minix and linux are worlds apart
internally: totally different principles in all things from interrupt
handling to process control and memory management.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux,comp.os.coherent
Subject: Re: Are Linux executables compatable with Coherent 4.0?
Message-ID: <1992Jul16.222559.16115@klaava.Helsinki.FI>
Date: 16 Jul 92 22:25:59 GMT
References: <SJE.92Jul16142750@xylos.ma30.bull.com>
Distribution: comp
Organization: University of Helsinki
Lines: 34
In article <SJE.92Jul16142750@xylos.ma30.bull.com> sje@xylos.ma30.bull.com writes:
>The beta version of MWC Coherent 4.0 (32 bit flat addressing for the
>386+ CPU family) claims that it has SCO executable compatability for
>character I/O programs at the Intel Binary Interoperatibility Level
>(or whatever). MWC has gotten gcc to run allowing the production of
>ASNI C applications. However, there are only a limited number (less
>than 10) of officially converted applications. Given the apparently
>large number of programs now working under Linux, I was wondering if
>any of the Linux binaries, particularly gcc, may be run under Coherent
>4.0 without modification. Also, it would be interesting if the
>reverse was true.
No, linux binaries won't work under Coh4.0 nor vice versa. I don't know
if the actual header is a problem (linux uses the standard a.out header
that gcc produces), but system calls aren't handled the same way. I
personally think binary compatability is evil (or at least unnecessary)
and in most cases just forces old mistakes on a new product etc (just
look at DOS). And as there aren't any binaries available with the
standard i386 ABI anyway that I could afford and want to run, I saw no
reason to even try.
[ Not to mention the fact that I haven't got any information at all on
the "standard" binary interface - which makes things a bit hard to
program :-) ]
Of course, somebody might try to write a system call emulator that does
the necessary translations, but it would probably be pretty ugly. I
don't even know how a system call is handled under normal i386 unices:
linux uses "int $0x80" with all the necessary info in the registers, but
there are several other possibilities available (jumping through a
trap-gate with or without stack copying etc), and the chances that I
would hit on the same interface as other 386-unices are pretty slim.
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Good comm program?
Message-ID: <1992Jul17.194456.8136@klaava.Helsinki.FI>
Date: 17 Jul 92 19:44:56 GMT
References: <1992Jul17.142447.16334@athena.mit.edu>
Organization: University of Helsinki
Lines: 27
In article <1992Jul17.142447.16334@athena.mit.edu> chchen@stat.fsu.edu writes:
>
>3.kermit is good but no rz, sz. I have tried to use them in kermit's
> command line (! rz) but it seems that rz can not find the com port
> , just waiting there.
The way I have rz/sz set up is to get one of the newer versions that
open "/dev/tty" explicitly in rbsb.c, and change that open to
"/dev/modem". After that, you can link /dev/modem to whatever device
you use, and rz/sz will happily use it directly. The normal rz/sz
behaviour requires the communication program to know about controlling
terminals, and setting it up correctly for rz/sz.
Additionally, making /tmp/rzlog and /tmp/szlog (usually symbolic) links
to /dev/tty means you get the verbose output to the screen: at a kermit
session I just type "^\ C" to get to the kermit prompt, and then "! rz
-vv" to receive using zmodem (or "! sz -bvv xxxx" to send). After
having set up things like the above, I get a nice verbose output (thanks
to the 'vv' flags) of how far the down/up-load has progressed.
Naturally, there are other ways you can set things up, and this just
happens to be the way I use it. Having hardcoded /dev/modem to be the
device sz/rz uses may not work in all circumstances (ie rz/sz won't work
if you have several dial-in lines or similar), but it works for me and
simplifies a lot of things.
Linus
===========================
===========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Floppies (was Re: File system issues!)
Message-ID: <1992Jul15.180004.20299@klaava.Helsinki.FI>
Date: 15 Jul 92 18:00:04 GMT
References: <1992Jul10.164650.2229@rs6000.cmp.ilstu.edu> <1992Jul12.104841.2039@klaava.Helsinki.FI> <1992Jul14.150258.29853@hubcap.clemson.edu>
Organization: University of Helsinki
Lines: 26
In article <1992Jul14.150258.29853@hubcap.clemson.edu> dawill@hubcap.clemson.edu (david williams) writes:
>
> I'll say one thing for the floppy driver - it's much faster than the
>MS_DOG floppy. I was exceeding pissed at my 386 floppy performance,
>and had pretty much given up on my controller as the problem. Not so!
>Running floppy I/O under Linux is a breath of fresh air, so it's not my
>hardware... It's a problem with MS_LOSS. Once more, proof that Linux
>is a really nice system.
This is due to the track-buffering: linux is pretty good at reading
sequential data (as in tar-files etc), but performance isn't that good
if you use the floppy for a filesystem (although the buffer cache does
help in that case).
> Anybody have an idea why MS-DOG is so slow in comparison with Linux
>if the floppy drivers for Linux are in such a sad state?
It's not that the driver isn't good: the linux drivers work pretty well
(with the exception of some problems), and they do a lot of smart
things: it's just that the actual code to do it isn't pretty. That
means potential bugs are hard to find, but it doesn't necessarily mean
the driver is slow. I'd like to start over on a clean slate, but it's
hard to find the energy when the current driver works as well as it
does.
Linus
============================
============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: problems with the kernel mathcode ?
Keywords: irit 3.0 modelling program with X11-Interface
Message-ID: <1992Jul14.165646.14572@klaava.Helsinki.FI>
Date: 14 Jul 92 16:56:46 GMT
References: <1992Jul14.090231.25102@Informatik.TU-Muenchen.DE>
Organization: University of Helsinki
Lines: 25
In article <1992Jul14.090231.25102@Informatik.TU-Muenchen.DE> menes@Informatik.TU-Muenchen.DE (Rainer Menes) writes:
>
>Yesterday I complied the 0.96cpl1 kernel, and with this kernel the program
>hang in all sitiations (without gdb, with gdb and stepi).
If you are using a 386-387 combination, there is a bug in the
IRQ13-handling code of 0.96c.pl1 - when I changed the IRQ's, I didn't
remember about the (stupid IBM-imposed) special handling of the 387
errors on the AT architecture. This particular bug leads to hangups at
math-errors in some circumstances. It shouldn't happen on 486 machines,
although I'm not 100% sure.
Other known problems with 0.96c.pl1 are: you can't use IRQ9 for the
serial lines due to a typo in irq.c. And due to a thinko in serial.c,
the IRQ switching of the serial lines doesn't actually work. I assume
this was to be expected, as the IRQ code was totally rewritten, but it's
a pity in any case: I had hoped c.pl1 would be reasonably stable.
As it is, I'll have to make pl2 available soonish: I hope to get the
select() code finally cleaned up before that, but I'll make the patch
available again the upcoming weekend if possible. The 0.96c.pl2 kernel
will contain the bus-mouse driver and the bug-fixes: if the SCSI drivers
can be updated, I might do that too. No real new features.
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: New Bus Mouse Driver patches for 96c-patchlevel1
Message-ID: <1992Jul15.180739.20524@klaava.Helsinki.FI>
Date: 15 Jul 92 18:07:39 GMT
References: <63336@hydra.gatech.EDU> <63338@hydra.gatech.EDU>
Organization: University of Helsinki
Lines: 12
In article <63338@hydra.gatech.EDU> gt7080a@prism.gatech.EDU (Nathan I. Laredo) writes:
>I should probably mention that the mouse driver is on
>banjo.concert.net as mouse96c1.tar.Z in /pub/Linux/Incoming
>and should be on tsx-11 sometime or other (I sent it there
>as well) in the next few weeks.
He also sent it to me by mail (correct procedure), and as I was cleaning
up the IRQ and select() code anyway, it went in with my changes. Expect
the mouse-driver in 0.96c.pl2 (out Saturday as usual). I'll want to
hear if the select() routines work for the mouse as well.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 0.96c second patch
Summary: it's out
Keywords: 0.96c patch
Message-ID: <1992Jul18.205448.25947@klaava.Helsinki.FI>
Date: 18 Jul 92 20:54:48 GMT
Organization: University of Helsinki
Lines: 92
[ This already went out to the normal linux-activists list, so if you
got it that way, you can ignore this post. BTW, I have some reports
that some messages from over here don't make it all the way to the US,
so if you don't see this, mail me :-]
The subject pretty much says it all: I've sent out the "weekly patch"
and I'd be very interested in comments. As with patch1, there are some
very fundamental changes in the kernel, and they might have some
problems. I'd want as many as possible to test out linux-0.96c.pl2, as
that has always been the best way to test out the changes. Everything
works on my machine, but that doesn't guarantee it will work on other
setups...
The MAJOR change in 0.96c.pl2 is the totally rewritten sleep/wakeup
code. That, together with the IRQ code introduced in pl1 and slightly
edited in pl2, means that two very fundamental things in the linux
kernel have changed in the last two weeks. The code is cleaner, easier
to add devices to, and hopefully faster, but it's still a bit risky to
change this kind of very low-level behaviour.
Select() is now implemented using the vfs jump tables, and thanks to the
better sleep/wakup interface, select() performance should be noticeably
better. At least xload seems to give lower load-averages, and I hope
ka9q will work better with the new kernel. Note that things like the
tty code doesn't yet take full advantage of the new features the
rewritten sleep offers, but I wanted to get a good testing-release out
before actually tweaking all the routines to use the new interface.
The IRQ routines have changed slightly, and all known bugs are fixed.
While I'm most interested to hear comments about the IRQ and
select/sleep/wakup code, there are a few other changes in pl2:
- Swiss keyboard support.
- Screen blanking now only reacts to key-presses and kernel messages:
normal tty output doesn't make the screen unblank.
- DOS-fs version 5 is in. It wouldn't hurt to try it out. It's
somewhat alpha still, but it seems to work. mtools should be a thing of
the past once the dosfs is a bit more tested.
- core-file magic number, and a minor bug in ptrace is fixed
- a bus-mouse is supported. I'd like to hear if it still works after I
did the select() patches "blind" (I can't test it on my machine).
- iopl changing is possible (but requires root priviledges): this
allows access to all IO ports, as well as the interrupt flag. Don't use
it unless /absolutely/ necessary: a bug in your program will most likely
crash the machine if you are running with IO priviledges. It's needed
for some X VGA drivers.
As a result of all the changes, the diff is pretty big. Apply and build
it with something like:
cd /usr/src
zcat linux-0.96c.patch2.Z | patch -p0
cd linux
make dep
make clean
make Image
assuming you have the 0.96c.pl1 kernel in /usr/src/linux. I've had some
reports that my patches won't always go in cleanly: I know for a fact
that patch1 patches cleanly (I rebuilt 0.96c.pl1 by downloading it all
from banjo), so the error is in your end.
Possible problems:
- The VESA code in setup.S has some problems. I haven't even looked
into it yet, so if it won't work for you, please either (a) use the
unpatched setup.S from 0.96c, or (b) try to find the problem and tell
me. (b) is preferable, of course. I'd like to have VESA support, but
if the bug isn't found, I'll have to use the non-VESA version for 0.97.
- The IRQ code in 0.96c.pl1 could overrun the stack if linux got
un-ending interrupt requests, resulting in a re-boot. With pl2, this
shouldn't happen: linux should print out something like "Recursive
interrupt on IRQx. Shutting down" and simply disable the problematic
IRQ line. If you see this message, I'd be very interested to hear about
it (which IRQ, what devices you have, etc).
- And any new or old bugs I haven't found yet.
I have one report that 0.96c.pl1 has problems with the inode table, and
panics on bootup with a "no more inodes in mem" report. Can anybody
confirm this sighting? I haven't found the reason for it, and haven't
seen it myself. I'm hoping it's an installation problem, but if anybody
else sees the same behaviour, I'm SOL.
Linus
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.96c second patch
Keywords: 0.96c patch
Message-ID: <1992Jul18.224304.19011@klaava.Helsinki.FI>
Date: 18 Jul 92 22:43:04 GMT
References: <1992Jul18.205448.25947@klaava.Helsinki.FI>
Organization: University of Helsinki
Lines: 7
Oops. I forgot to mention that the sleep/wakeup code changes in patch2
change the kernel data structures enough to freak out 'ps' etc programs
that go mucking around with /dev/kmem. It is not enough just to do a
"ps U" to update the nametables: you actually have to recompile the ps
package.
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Termios question: Semantics of VMIN/VTIME on Linux/SunOS ?
Message-ID: <1992Jul19.201601.13942@klaava.Helsinki.FI>
Date: 19 Jul 92 20:16:01 GMT
References: <9207151400@gandalf.moria> <arumble.711530378@extro.ucc.su.OZ.AU>
Organization: University of Helsinki
Lines: 39
In article <arumble.711530378@extro.ucc.su.OZ.AU> arumble@extro.ucc.su.OZ.AU (Anthony Rumble) writes:
>michael@gandalf.moria (Michael Haardt) writes:
>
>> buff.c_cc[VMIN]=5;
>> buff.c_cc[VTIME]=1;
>> tcsetattr(file,TCSANOW,&buff);
>>I am no termios expert, but this code is intended to let a
>> read(file,buffer,sizeof(buffer));
>>
>>read as much characters as available, max sizeof(buffer) and return
>>after a short timeout if there are none. Ok?
The way linux does this is (a) wait for at least one character (VMIN > 0
and VTIME > 0), (b) read as many characters as possible, with a timeout
of max 0.10 seconds between any of the first 5 characters. Thus the
read can return:
-1:
EINTR - a signal happened (but you usually don't see this: the
read is mostly re-tried after the signal is handled)
1-5:
linux got one character, followed by four characters within the
inter-character timeout given (VTIME = 1 -> 0.1 sec).
6-sizeof(buffer):
after the fifth character there was actually more data
available, without any timeout.
>I was under the impression that this should actually return on
>either 5 characters recieved, or sizeof(buffer), or timeout..
The only thing that I have that explains this all is the SunOS manpage,
so I cannot actually guarantee the above behaviour by linux is correct.
Could somebody with the POSIX standard available actually check it out?
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Termios question: Semantics of VMIN/VTIME on Linux/SunOS ?
Message-ID: <1992Jul21.183946.9138@klaava.Helsinki.FI>
Date: 21 Jul 92 18:39:46 GMT
References: <arumble.711530378@extro.ucc.su.OZ.AU> <1992Jul19.201601.13942@klaava.Helsinki.FI> <arumble.711729320@extro.ucc.su.OZ.AU>
Organization: University of Helsinki
Lines: 60
In article <arumble.711729320@extro.ucc.su.OZ.AU> arumble@extro.ucc.su.OZ.AU (Anthony Rumble) writes:
>torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>
>>The way linux does this is (a) wait for at least one character (VMIN > 0
>>and VTIME > 0), (b) read as many characters as possible, with a timeout
>>of max 0.10 seconds between any of the first 5 characters. Thus the
>>read can return:
>
>Errm.. Question.. Can you think of a possible USE of this?
>It dosen't seem quite logical to do it this way, it would be
>much more usefull to return on either 5 chars OR timeout regardless
>on the first character..
Ours is not to wonder why... Frankly, the above is what the SunOS
man-pages seem to say, and as that's the only info I have on the
subject, that's how linux does things. SunOS seems to be pretty close
to posix, and following the man-pages has so far worked pretty well. I
don't know the reasons for the POSIX behaviour, and the man-pages might
be wrong (and I might even have misunderstood), but I'd rather be
conforming to weird standards than have problems porting programs later
on when they expect that behaviour.
As I already mentioned, I'm very open to changing the behaviour: but I
need to have actual "chapter and verse" from the posix standard before I
start changing things. The current behaviour works with a lot of
programs, and conforms to the only docs I have, so I really need some
strong arguments to change it.
The VMIN/VTIME arguments are currently understood by linux as (note:
this info is only used when not in canonical mode):
VTIME = 0 VMIN = 0
Instant return, reading as many characters as possible from the
terminal.
VTIME = 0 VMIN > 0
No timeout, and we return once VMIN characters have been read.
We still might return before that in case of signals etc, and if
there are more characters available, they will be read.
VTIME > 0 VMIN = 0
This is a simple timeout-read: we wait VTIME*0.1 seconds or
until at least one character has arrived. The read will not
take more than VTIME*0.1 sec, not counting scheduling etc
overhead.
VTIME > 0 VMIN > 0
VTIME*0.1 seconds is an inter-character timer that is started
after the first character is received, and restarted at each new
character until VMIN characters have been received. The read()
returns at least one character (again not counting signals), as
the timer comes into play only /between/ characters.
All the above have an upper limit of the given buffer-size: none have a
true lower limit (as they can return less than VMIN characters). VMIN
isn't meant to be used for packet-sized communication: it's just used to
help decide when/how to accept timeouts. Can somebody please confirm if
the above is actually the correct behaviour?
Linus
============================
============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Better serial throughput: another approach
Message-ID: <1992Jul21.201858.11059@klaava.Helsinki.FI>
Date: 21 Jul 92 20:18:58 GMT
References: <Jul.19.16.41.19.1992.22509@dumas.rutgers.edu> <2A6C23D4.5D7F@tct.com>
Organization: University of Helsinki
Lines: 56
In article <2A6C23D4.5D7F@tct.com> chip@tct.com (Chip Salzenberg) writes:
>According to hedrick@dumas.rutgers.edu (Charles Hedrick):
>>I've finally concluded that there's just too much code being
>>executed per character.
>
>There is another way, as SCO does:
>
> At serial interrupt: just store the character in a queue and return.
> Don't go through scheduler, just return.
>
> At clock interrupt: pull characters off the queues and do the rest
> of the processing that is currently happening at serial interrupt
> time. Then run the scheduler, _once_.
>
>Presto: minimum-overhead serial I/O.
This is in fact how linux does it already: the problem has been to find
the offending code. As I haven't actually seen the character loss, I
originally thought it was either bad interrupt latency or simply too
slow serial interrupt routines. After more testing (mainly thanks to
hedrick), it seems the problem is actually the clock interrupt routine:
it's too slow.
"Why would the system care how slow the clock interrupt is?" - the
reason is simple: interrupts are enabled while the serial interrupt
happens, so the following can happen:
serial interrupt received: handler started
timer interrupt received: immediate response
timer interrupt does the serial copying, returns
serial handler returns.
The result is that while the serial code is fast enough, it can get
interrupted by the timer interrupt (which happens 100 times a second:
not too surprising if it happens while the serial handler is active
every now and then).
The timer interrupt isn't that complicated, but it does do the
copy_to_cooked routine, which can take some time. So, there are four
possibilities: (a) make the serial interrupt handler atomic or (b) speed
up the copy_to_cooked routine or (c) move copy_to_cooked from within the
timer-interrupt to some less time-critical place and (d) rewrite the
general tty handlers totally to have less need for the copy-to-cooked
routines.
I'm in fact looking into all four possibilities, and 0.97 will contain
one or several of the fixes. One way of getting slightly better
performance already is to use the patch by hedrick, which essentially
speeds up copy_to_cooked by making some of the help-function inline etc.
[ Note that you cannot right now use SA_INTERRUPT to install a serial
handler that is totally atomic: it's still interruptible in the general
IRQ handling code. I'll have to change this for the next version
anyway, as the old problems with some (buggy?) harddisks are back ]
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: /dev/ttys? not responding
Message-ID: <1992Jul23.103716.29243@klaava.Helsinki.FI>
Date: 23 Jul 92 10:37:16 GMT
References: <1992Jul22.235626.17486@ncsu.edu>
Organization: University of Helsinki
Lines: 24
In article <1992Jul22.235626.17486@ncsu.edu> doogie@garfield.catt.ncsu.edu (Jeff House) writes:
>
>I did the following: [ edited ]
>
>echo "ATDT5551111" > /dev/ttys0
>
> [ some more editing ] Neither case dialed, and
>when I did:
>
>cat /dev/ttys0
>
>"ATDT5551111" was echoed. My modem seems not to be accepting commands.
This is pretty much what should happen: hayes-compatible modems expect a
carriage return ('\r') after the command, and the above just sends the
normal unix line-feed instead. As the modem is echoing you, you do have
a good connection to it, so things should work after correcting the
above to:
$ echo -e -n "atdt5551111\015"
or similar. Or get kermit, and type the above in directly.
Linus
==================
==================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: sigaction sys-call
Message-ID: <1992Jul25.114912.17913@klaava.Helsinki.FI>
Date: 25 Jul 92 11:49:12 GMT
References: <1992Jul25.110852.24366@fwi.uva.nl>
Organization: University of Helsinki
Lines: 14
In article <1992Jul25.110852.24366@fwi.uva.nl> vesseur@fwi.uva.nl (Joep JJ Vesseur) writes:
>
>Looking around in the include files, i came across a line that said
> "Ok, I haven't implemented sigactions, but trying to keep headers POSIX"
> (/usr/include/signal.h)
>but in the kernel source file signal.c there is code to implement
>sigaction. Is this some sort of dummy code, or is signal.h out of date and
>is sigaction fully functional?
Sorry: I don't write too many comments, and when I do they seem to
become obsolete. sigaction() is completely implemented, and has been
since 0.12 or something like that..
Linus
=============================
=============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: C_A_D=0
Message-ID: <1992Jul27.185353.5771@klaava.Helsinki.FI>
Date: 27 Jul 92 18:53:53 GMT
References: <1992Jul27.180447.28246@ifi.uio.no>
Organization: University of Helsinki
Lines: 38
In article <1992Jul27.180447.28246@ifi.uio.no> janl@ifi.uio.no (Jan Nicolai Langfeldt) writes:
>
>I have mucked about with the kernel lately (0.96cpl2). When I set the
>C_A_D varaible to 0 (to avoid reboot on pressing C-A-D) (and compile,
>reboot :-). After login in and executing sync I press C-A-D and the
>system locks, completely... Anyone with similar experiences?
Setting 'C_A_D = 0' results in init being sent a SIGINT instead of a
instant reboot when ctrl-alt-del is pressed. If you have the old init
that doesn't handle a SIGINT, you get a very dead system: init dies, and
everything essentially locks.
There are two possible solutions to this:
(a) get one of the newer init packages that handle SIGINT gracefully,
and do a clean shutdown.
(b) apply this "patch" (or wait for my next release):
in linux/kernel/sys.c, ctrl_alt_del():
! if (task[1])
send_sig(SIGINT,task[1],1);
should be:
! if (task[1] && task[1].sigaction[SIGINT-1].sa_handler)
send_sig(SIGINT,task[1],1);
The patch essentially checks that a signal handler is present before
sending the SIGINT. That way old init packages won't be surprised.
Linus
PS. I'll probably make patch3 to 0.96c available sometime later this
week: the main new feature is a dynamic buffer-cache. The original
patches were by oreilly, but have been almost totally rewritten by me.
The IRQ code has also been edited and is hopefully stable now.
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: C_A_D=0
Message-ID: <1992Jul27.191256.6181@klaava.Helsinki.FI>
Date: 27 Jul 92 19:12:56 GMT
References: <1992Jul27.180447.28246@ifi.uio.no> <1992Jul27.185353.5771@klaava.Helsinki.FI>
Organization: University of Helsinki
Lines: 21
Never write in a patch by hand: it usually gets messed up...
In article <1992Jul27.185353.5771@klaava.Helsinki.FI> I wrote:
>
>(b) apply this "patch" (or wait for my next release):
>
> in linux/kernel/sys.c, ctrl_alt_del():
>
>! if (task[1])
> send_sig(SIGINT,task[1],1);
>
> should be:
>
>! if (task[1] && task[1].sigaction[SIGINT-1].sa_handler)
^^^
> send_sig(SIGINT,task[1],1);
the 'task[1].sigaction' should obviously be a 'task[1]->sigaction', or
it won't even compile...
Linus "shamefaced" Torvalds
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: MicroSoft Bus Mouse v.s. Linux 0.96c(pl2)
Message-ID: <1992Jul29.092511.18926@klaava.Helsinki.FI>
Date: 29 Jul 92 09:25:11 GMT
References: <1992Jul27.191720.2986@uwm.edu> <2835@ariel.its.unimelb.EDU.AU>
Organization: University of Helsinki
Lines: 20
In article <2835@ariel.its.unimelb.EDU.AU> rab@ariel.its.unimelb.EDU.AU (Richard Alan Brown) writes:
>
>I have a Microsoft InPort mouse, and it certainly doesn't work. However,
>Nathan Laredo advises me that InPort mice are really just serial mice.
>My InPort mouse card uses IRQ 5 and according to the docs uses port address
>0x23C-0x23F, so i tried:
>
> % setserial /dev/tty2 0x23C 5
>
>and locked up the system quite nicely! I have no idea what to do next...
>any ideas ??
setserial got broken in pl1 or pl2: it locks the machine under some
circumstances (actually, anything that opens a serial device that has
the wrong parameters will do it). I'll make 0.97 available this weekend
(dynamic buffers and the new SCS drivers), and the problem should be
corrected. I'm still testing out some bug that seems to occur when
memory is tight, but 0.97 should be pretty stable.
Linus
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Problem with ld?
Summary: 0.97 out soon
Message-ID: <1992Jul30.001305.5863@klaava.Helsinki.FI>
Date: 30 Jul 92 00:13:05 GMT
References: <NEGAARD.92Jul29095314@fungus.aero.org> <NEGAARD.92Jul29141913@fungus.aero.org>
Organization: University of Helsinki
Lines: 42
In article <NEGAARD.92Jul29141913@fungus.aero.org> negaard@aero.org (Eric Negaard) writes:
>
>At the time I was doing the compiles I was running X, xclock, x11emacs, and
>a couple of xterm's. Free was reporting somewhat less than 1 Mb physical
>memory free. So I killed off a bunch of processes and the compiles/links
>started running fine. At that time, another program that I was having
>trouble with started working too, so apparantly there is a real problem
>with virtual memory. This is all happening with a 0.96c pl 2 kernel.
There is indeed a problem with VM and disk-intensive tasks - it's a
race-condition where the page-IO requests can get re-ordered, resulting
in weird error results. Linking big programs is one of the better ways
to see this problem. The problem manifests itself as bad user-level
pages, and often results in a segmentation fault or just incorrect data.
The solution is to wait 2 days or so for 0.97 that corrects it (I just
/love/ finding bugs before any beta-tester does, and being able to come
up with an instant fix). 0.97 also contains the new SCSI drivers, the
dynamic buffer code and some other nifty and nice tricks. I don't know
about serial performance, but limited tests (yes, I have actually tested
something) have indicated that it's finally starting to get better.
( BTW: I won't make patches from 0.96c.pl2 -> 0.97 available unless
somebody explicitly asks for them: they are going to be big. If you
think you /need/ patches, mail me, and I'll do them. Maybe a couple of
days late, but I'll do them )
0.97 will likely be out Friday or Saturday, and has these changes:
- The new SCSI drivers (drew & co)
- IRQ code should finally be stable
- faster, smaller, atomic serial interrupts: better performance
- bynamic buffer-cache (original diffs by oreilly, but I rewrote them)
- removed races in VM code
- multiple minor changes in hd.c/floppy.c/efxfs/dosfs
- hooks for different-size buffers (but it's not actually ready yet)
Some things aren't there: I've gotten more patches than I could keep up
with, so if your patch was only partly used or not used at all, please
re-send. I haven't got time to go through archives or old mail finding
things I overlooked :-(
Linus
================
================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: New root disk utils compiled with new diraddr()?
Message-ID: <1992Jul31.202911.26270@klaava.Helsinki.FI>
Date: 31 Jul 92 20:29:11 GMT
References: <CORYWEST.92Jul31121404@lost.rice.edu>
Organization: University of Helsinki
Lines: 38
In article <CORYWEST.92Jul31121404@lost.rice.edu> corywest@rice.edu (Cory West) writes:
>
> Will the utils on the next release of the root disk be
>compiled with the correct readdr() so that they will be able to
>deal with the new ext file system?
The current (0.96) rootdisk (and mcc-interim) should already be compiled
with gcc-2.2.2, using the readdir() syscall. Most binaries that have
been made available in the last month should be good: looking at the
date-information at the ftp-sites is generally a a good indication
(although not 100% sure).
> I was trying to test out the
>ext file system, but I don't have the resources to recompile
>everything. When might we see this? When might the extfs move from
>beta to production?
The problem with the extended fs is now mostly a performance thing: the
fs might still be changed to use bigger block-sizes for faster
operation. Remy Card has shown interest, and I don't know if the final
ext-fs will be compatible with the current one. Having a 4kB blocksize
should speed up operations considerably, but while the kernel doesn't
yet completely support different sized buffers I can't promise anything
(0.97 has much code for it, but still some way to go).
The buffer-code changes in 0.97 might eventually also mean the DOS
interface gets faster: a 512-byte block-size is more natural for some
DOS operations, so it might be possible that you'll eventually see a
system that uses 512-byte buffers for msdos floppies, 1024-byte buffers
for the minix fs and bigger buffers for the extended fs.
The block drivers have to be made aware of the dynamic buffer-sizes etc,
and I'll have to write some code to stop the mixing of differently sized
buffers on the same device (which leads to madness). Right now (ie in
version 0.97) only the low-level buffer-code knows about the dynamic
sizes.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Birthday (was Re: Uptime found. Thanks to all)
Message-ID: <1992Jul31.221520.27288@klaava.Helsinki.FI>
Date: 31 Jul 92 22:15:20 GMT
References: <1992Jul30.211132.20101@cc.umontreal.ca>
Organization: University of Helsinki
Lines: 398
In article <1992Jul30.211132.20101@cc.umontreal.ca> duperval@ERE.UMontreal.CA (Duperval Laurent) writes:
>
>P.S. BTW, noone answered yet: when is Linux's birthday? Let's have a
>party!
I couldn't for the life of me remember when it all happened, and I don't
keep a diary, so I can't give you any exact dates for when linux "was
born". But I did start to wonder, so I started ftp'ing around for
archives of the comp.os.minix group (where I announced it), and this is
what I came up with (with some editing).
This is just a sentimental journey into some of the first posts
concerning linux, so you can happily press 'n' now if you actually
thought you'd get anything technical.
> From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
> Newsgroups: comp.os.minix
> Subject: Gcc-1.40 and a posix-question
> Message-ID: <1991Jul3.100050.9886@klaava.Helsinki.FI>
> Date: 3 Jul 91 10:00:50 GMT
>
> Hello netlanders,
>
> Due to a project I'm working on (in minix), I'm interested in the posix
> standard definition. Could somebody please point me to a (preferably)
> machine-readable format of the latest posix rules? Ftp-sites would be
> nice.
The project was obviously linux, so by July 3rd I had started to think
about actual user-level things: some of the device drivers were ready,
and the harddisk actually worked. Not too much else.
> As an aside for all using gcc on minix - [ deleted ]
Just a success-report on porting gcc-1.40 to minix using the 1.37
version made by Alan W Black & co.
> Linus Torvalds torvalds@kruuna.helsinki.fi
>
> PS. Could someone please try to finger me from overseas, as I've
> installed a "changing .plan" (made by your's truly), and I'm not certain
> it works from outside? It should report a new .plan every time.
So I was clueless - had just learned about named pipes. Sue me. This
part of the post got a lot more response than the actual POSIX query,
but the query did lure out arl from the woodwork, and we mailed around
for a bit, resulting in the Linux subdirectory on nic.funet.fi.
Then, almost two months later, I actually had something working: I made
sources for version 0.01 available on nic sometimes around this time.
0.01 sources weren't actually runnable: they were just a token gesture
to arl who had probably started to despair about ever getting anything.
This next post must have been from just a couple of weeks before that
release.
> From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
> Newsgroups: comp.os.minix
> Subject: What would you like to see most in minix?
> Summary: small poll for my new operating system
> Message-ID: <1991Aug25.205708.9541@klaava.Helsinki.FI>
> Date: 25 Aug 91 20:57:08 GMT
> Organization: University of Helsinki
>
>
> Hello everybody out there using minix -
>
> I'm doing a (free) operating system (just a hobby, won't be big and
> professional like gnu) for 386(486) AT clones. This has been brewing
> since april, and is starting to get ready. I'd like any feedback on
> things people like/dislike in minix, as my OS resembles it somewhat
> (same physical layout of the file-system (due to practical reasons)
> among other things).
>
> I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
> This implies that I'll get something practical within a few months, and
> I'd like to know what features most people would want. Any suggestions
> are welcome, but I won't promise I'll implement them :-)
>
> Linus (torvalds@kruuna.helsinki.fi)
>
> PS. Yes - it's free of any minix code, and it has a multi-threaded fs.
> It is NOT protable (uses 386 task switching etc), and it probably never
> will support anything other than AT-harddisks, as that's all I have :-(.
Judging from the post, 0.01 wasn't actually out yet, but it's close. I'd
guess the first version went out in the middle of September -91. I got
some responses to this (most by mail, which I haven't saved), and I even
got a few mails asking to be beta-testers for linux.
After that just a few general answers to quesions on the net:
> From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
> Newsgroups: comp.os.minix
> Subject: Re: What would you like to see most in minix?
> Summary: yes - it's nonportable
> Message-ID: <1991Aug26.110602.19446@klaava.Helsinki.FI>
> Date: 26 Aug 91 11:06:02 GMT
> Organization: University of Helsinki
>
> In article <1991Aug25.234450.22562@nntp.hut.fi> jkp@cs.HUT.FI (Jyrki Kuoppala) writes:
> >> [re: my post about my new OS]
> >
> >Tell us more! Does it need a MMU?
>
> Yes, it needs a MMU (sorry everybody), and it specifically needs a
> 386/486 MMU (see later).
>
> >
> >>PS. Yes - it's free of any minix code, and it has a multi-threaded fs.
> >>It is NOT protable (uses 386 task switching etc)
> >
> >How much of it is in C? What difficulties will there be in porting?
> >Nobody will believe you about non-portability ;-), and I for one would
> >like to port it to my Amiga (Mach needs a MMU and Minix is not free).
>
> Simply, I'd say that porting is impossible. It's mostly in C, but most
> people wouldn't call what I write C. It uses every conceivable feature
> of the 386 I could find, as it was also a project to teach me about the
> 386. As already mentioned, it uses a MMU, for both paging (not to disk
> yet) and segmentation. It's the segmentation that makes it REALLY 386
> dependent (every task has a 64Mb segment for code & data - max 64 tasks
> in 4Gb. Anybody who needs more than 64Mb/task - tough cookies).
>
> It also uses every feature of gcc I could find, specifically the __asm__
> directive, so that I wouldn't need so much assembly language objects.
> Some of my "C"-files (specifically mm.c) are almost as much assembler as
> C. It would be "interesting" even to port it to another compiler (though
> why anybody would want to use anything other than gcc is a mystery).
[ editors note: linux has in fact gotten more portable with newer
versions: there was a lot more assembly in the early versions. Not that
anybody in their right mind would try to port it even now ]
> Unlike minix, I also happen to LIKE interrupts, so interrupts are
> handled without trying to hide the reason behind them (I especially like
> my hard-disk-driver. Anybody else make interrupts drive a state-
> machine?). All in all it's a porters nightmare.
>
> >As for the features; well, pseudo ttys, BSD sockets, user-mode
> >filesystems (so I can say cat /dev/tcp/kruuna.helsinki.fi/finger),
> >window size in the tty structure, system calls capable of supporting
> >POSIX.1. Oh, and bsd-style long file names.
>
> Most of these seem possible (the tty structure already has stubs for
> window size), except maybe for the user-mode filesystems. As to POSIX,
> I'd be delighted to have it, but posix wants money for their papers, so
> that's not currently an option. In any case these are things that won't
> be supported for some time yet (first I'll make it a simple minix-
> lookalike, keyword SIMPLE).
>
> Linus (torvalds@kruuna.helsinki.fi)
>
> PS. To make things really clear - yes I can run gcc on it, and bash, and
> most of the gnu [bin/file]utilities, but it's not very debugged, and the
> library is really minimal. It doesn't even support floppy-disks yet. It
> won't be ready for distribution for a couple of months. Even then it
> probably won't be able to do much more than minix, and much less in some
> respects. It will be free though (probably under gnu-license or similar).
Well, obviously something worked on my machine: I doubt I had yet gotten
gcc to compile itself under linux (or I would have been too proud of it
not to mention it). Still before any release-date.
Then, October 5th, I seem to have released 0.02. As I already
mentioned, 0.01 didn't actually come with any binaries: it was just
source code for people interested in what linux looked like. Note the
lack of announcement for 0.01: I wasn't too proud of it, so I think I
only sent a note to everybody who had shown interest.
> From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
> Newsgroups: comp.os.minix
> Subject: Free minix-like kernel sources for 386-AT
> Message-ID: <1991Oct5.054106.4647@klaava.Helsinki.FI>
> Date: 5 Oct 91 05:41:06 GMT
> Organization: University of Helsinki
>
> Do you pine for the nice days of minix-1.1, when men were men and wrote
> their own device drivers? Are you without a nice project and just dying
> to cut your teeth on a OS you can try to modify for your needs? Are you
> finding it frustrating when everything works on minix? No more all-
> nighters to get a nifty program working? Then this post might be just
> for you :-)
>
> As I mentioned a month(?) ago, I'm working on a free version of a
> minix-lookalike for AT-386 computers. It has finally reached the stage
> where it's even usable (though may not be depending on what you want),
> and I am willing to put out the sources for wider distribution. It is
> just version 0.02 (+1 (very small) patch already), but I've successfully
> run bash/gcc/gnu-make/gnu-sed/compress etc under it.
>
> Sources for this pet project of mine can be found at nic.funet.fi
> (128.214.6.100) in the directory /pub/OS/Linux. The directory also
> contains some README-file and a couple of binaries to work under linux
> (bash, update and gcc, what more can you ask for :-). Full kernel
> source is provided, as no minix code has been used. Library sources are
> only partially free, so that cannot be distributed currently. The
> system is able to compile "as-is" and has been known to work. Heh.
> Sources to the binaries (bash and gcc) can be found at the same place in
> /pub/gnu.
>
> ALERT! WARNING! NOTE! These sources still need minix-386 to be compiled
> (and gcc-1.40, possibly 1.37.1, haven't tested), and you need minix to
> set it up if you want to run it, so it is not yet a standalone system
> for those of you without minix. I'm working on it. You also need to be
> something of a hacker to set it up (?), so for those hoping for an
> alternative to minix-386, please ignore me. It is currently meant for
> hackers interested in operating systems and 386's with access to minix.
>
> The system needs an AT-compatible harddisk (IDE is fine) and EGA/VGA. If
> you are still interested, please ftp the README/RELNOTES, and/or mail me
> for additional info.
>
> I can (well, almost) hear you asking yourselves "why?". Hurd will be
> out in a year (or two, or next month, who knows), and I've already got
> minix. This is a program for hackers by a hacker. I've enjouyed doing
> it, and somebody might enjoy looking at it and even modifying it for
> their own needs. It is still small enough to understand, use and
> modify, and I'm looking forward to any comments you might have.
>
> I'm also interested in hearing from anybody who has written any of the
> utilities/library functions for minix. If your efforts are freely
> distributable (under copyright or even public domain), I'd like to hear
> from you, so I can add them to the system. I'm using Earl Chews estdio
> right now (thanks for a nice and working system Earl), and similar works
> will be very wellcome. Your (C)'s will of course be left intact. Drop me
> a line if you are willing to let me use your code.
>
> Linus
>
> PS. to PHIL NELSON! I'm unable to get through to you, and keep getting
> "forward error - strawberry unknown domain" or something.
Well, it doesn't sound like much of a system, does it? It did work, and
some people even tried it out. There were several bad bugs (and there
was no floppy-driver, no VM, no nothing), and 0.02 wasn't really very
useable.
0.03 got released shortly thereafter (max 2-3 weeks was the time between
releases even back then), and 0.03 was pretty useable. The next version
was numbered 0.10, as things actually started to work pretty well. The
next post gives some idea of what had happened in two months more...
> From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
> Newsgroups: comp.os.minix
> Subject: Re: Status of LINUX?
> Summary: Still in beta
> Message-ID: <1991Dec19.233545.8114@klaava.Helsinki.FI>
> Date: 19 Dec 91 23:35:45 GMT
> Organization: University of Helsinki
>
> In article <469@htsa.htsa.aha.nl> miquels@maestro.htsa.aha.nl (Miquel van Smoorenburg) writes:
> >Hello *,
> > I know some people are working on a FREE O/S for the 386/486,
> >under the name Linux. I checked nic.funet.fi now and then, to see what was
> >happening. However, for the time being I am without FTP access so I don't
> >know what is going on at the moment. Could someone please inform me about it?
> >It's maybe best to follow up to this article, as I think that there are
> >a lot of potential interested people reading this group. Note, that I don't
> >really *have* a >= 386, but I'm sure in time I will.
>
> Linux is still in beta (although available for brave souls by ftp), and
> has reached the version 0.11. It's still not as comprehensive as
> 386-minix, but better in some respects. The "Linux info-sheet" should
> be posted here some day by the person that keeps that up to date. In
> the meantime, I'll give some small pointers.
>
> First the bad news:
>
> - Still no SCSI: people are working on that, but no date yet.
> Thus you need a AT-interface disk (I have one report that it
> works on an EISA 486 with a SCSI disk that emulates the
> AT-interface, but that's more of a fluke than anything else:
> ISA+AT-disk is currently the hardware setup)
As you can see, 0.11 had already a small following. It wasn't much, but
it did work.
> - still no init/login: you get into bash as root upon bootup.
That was still standard in the next release.
> - although I have a somewhat working VM (paging to disk), it's not
> ready yet. Thus linux needs at least 4M to be able to run the
> GNU binaries (especially gcc). It boots up in 2M, but you
> cannot compile.
I actually released a 0.11+VM version just before Christmas -91: I
didn't need it myself, but people were trying to compile the kernel in
2MB and failing, so I had to implement it. The 0.11+VM version was
available only to a small number of people that wanted to test it out:
I'm still surprised it worked as well as it did.
> - minix still has a lot more users: better support.
>
> - it hasn't got years of testing by thousands of people, so there
> are probably quite a few bugs yet.
>
> Then for the good things..
>
> - It's free (copyright by me, but freely distributable under a
> very lenient copyright)
The early copyright was in fact much more restrictive than the GNU
copyleft: I didn't allow any money at all to change hands due to linux.
That changed with 0.12.
> - it's fun to hack on.
>
> - /real/ multithreading filesystem.
>
> - uses the 386-features. Thus locked into the 386/486 family, but
> it makes things clearer when you don't have to cater to other
> chips.
>
> - a lot more... read my .plan.
>
> /I/ think it's better than minix, but I'm a bit prejudiced. It will
> never be the kind of professional OS that Hurd will be (in the next
> century or so :), but it's a nice learning tool (even more so than
> minix, IMHO), and it was/is fun working on it.
>
> Linus (torvalds@kruuna.helsinki.fi)
>
> ---- my .plan --------------------------
> Free UNIX for the 386 - coming 4QR 91 or 1QR 92.
>
> The current version of linux is 0.11 - it has most things a unix kernel
> needs, and will probably be released as 1.0 as soon as it gets a little
> more testing, and we can get a init/login going. Currently you get
> dumped into a shell as root upon bootup.
>
> Linux can be gotten by anonymous ftp from 'nic.funet.fi' (128.214.6.100)
> in the directory '/pub/OS/Linux'. The same directory also contains some
> binary files to run under Linux. Currently gcc, bash, update, uemacs,
> tar, make and fileutils. Several people have gotten a running system,
> but it's still a hackers kernel.
>
> Linux still requires a AT-compatible disk to be useful: people are
> working on a SCSI-driver, but I don't know when it will be ready.
>
> There are now a couple of other sites containing linux, as people have
> had difficulties with connecting to nic. The sites are:
> Tupac-Amaru.Informatik.RWTH-Aachen.DE (137.226.112.31):
> directory /pub/msdos/replace
> tsx-11.mit.edu (18.172.1.2):
> directory /pub/linux
>
> There is also a mailing list set up 'Linux-activists@niksula.hut.fi'.
> To join, mail a request to 'Linux-activists-request@niksula.hut.fi'.
> It's no use mailing me: I have no actual contact with the mailing-list
> (other than being on it, naturally).
>
> Mail me for more info:
>
> Linus (torvalds@kruuna.Helsinki.FI)
>
> 0.11 has these new things:
>
> - demand loading
> - code/data sharing between unrelated processes
> - much better floppy drivers (they actually work mostly)
> - bug-corrections
> - support for Hercules/MDA/CGA/EGA/VGA
> - the console also beeps (WoW! Wonder-kernel :-)
> - mkfs/fsck/fdisk
> - US/German/French/Finnish keyboards
> - settable line-speeds for com1/2
As you can see: 0.11 was actually stand-alone: I wrote the first
mkfs/fsck/fdisk programs for it, so that you didn't need minix any more
to set it up. Also, serial lines had been hard-coded to 2400bps, as that
was all I had.
> Still lacking:
> - init/login
> - rename system call
> - named pipes
> - symbolic links
Well, they are all there now: init/login didn't quite make it to 0.12,
and rename() was implemented as a patch somewhere between 0.12 and 0.95.
Symlinks were in 0.95, but named pipes didn't make it until 0.96.
> 0.12 will probably be out in January (15th or so), and will have:
> - POSIX job control (by tytso)
> - VM (paging to disk)
> - Minor corrections
Actually, 0.12 was out January 5th, and contained major corrections. It
was in fact a very stable kernel: it worked on a lot of new hardware,
and there was no need for patches for a long time. 0.12 was also the
kernel that "made it": that's when linux started to spread a lot faster.
Earlier kernel releases were very much only for hackers: 0.12 actually
worked quite well.
That's all I found for 1991 - maybe it answered some questions.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Linux v. 0.97 is out
Summary: new version release
Keywords: 0.97 kernel
Message-ID: <1992Aug1.150838.11254@klaava.Helsinki.FI>
Date: 1 Aug 92 15:08:38 GMT
Organization: University of Helsinki
Lines: 99
[ I already sent this to the mailing-list, and it's the same
release-note, so if you already saw it, you can skip this ]
Linux version 0.97 is available as both a complete source-tree
(linux-0.97.tar.Z) and a bootimage (bootimage-0.97.Z) on the normal
ftp-sites. It's in incoming on tsx-11.mit.edu, so it will take a day or
two to actually show up, but it's available right now on
nic.funet.fi:
pub/OS/Linux/testing/Linus/
banjo.concert.net:
pub/Linux/Linus/
The nic.funet.fi-directory is under 'testing' not so much because this
would be a testing-release, but because the directory-setup is in
testing :-). I think 'testing' is unreadable, so you have to cd to the
directory blindly.
There is also a kernel-compilation README (written by Lars Wirzenius),
as well as a COPYING (which is just a pointer to the GNU copyleft). The
latter not because anything has changed, but because I got a few mails
pointing out that the copyright of linux wasn't too clear. That also
resulted in changing the '(C)'s in the source to 'Copyright'.
Changes in 0.97:
- The VESA-support was removed. I'd be happy to put it back once it
works on all hardware. Instead of the VESA-code, I finally put in
the automatic SVGA setup patches. See the top-level Makefile.
- The IRQ code has solidified, and should work on all machines. Not
all of the SCSI drivers use it yet, so I expect patches for that..
- Serial interrupts are handled slightly differently, and performance
should be up. I've sent out a few alpha-releases, and testing seems
to indicate that's actually true this time. Reactions have ranged
from "nice" to "wonderful" :-)
- The buffer-cache and memory management code has been edited quite a
bit. ps/free etc programs that reads kernel memory directly no
longer work, and even a recompilation won't be enough. They actually
need editing before they work.
The buffer-cache now grows and shrinks dynamically depending on how
much free memory there is. Shift+PrintScreen will give some memory
statistics. (Ctrl+PrSc gives task-info, ALT+PrSc gives current
register values).
The mm code changes removed some race-conditions in the VM code, and
I also tried to make the Out-of-swapspace error less severe (better
thrashing-detection etc).
- The super-block code has been cleaned up. Especially the extended fs
needs to be edited a bit to take advantage of the new setup, and I
expect Remy Card will have a patch out eventually.
- include-files have been moved around some more: there are still some
names that clash with the standard headers, but not many.
- Unswappable processes implemented: by default only 'init' is
unswappable. This is a bit safer in low-memory conditions, as at
least init won't die due to low memory. I also made killing init
impossible: if init doesn't recognize a signal, it simply won't get
it. Some other changes ("while (1) fork();" won't kill the machine
for non-root users etc)
- The new SCSI drivers are in. These make the kernel noticeably
bigger, but you can leave them out if you don't want them.
- The floppy- and hd-drivers print out more debugging-info in case of
errors: this might be irritating if you have hardware that works, but
often gives soft-errors. On the other hand, some old debugging-info
was removed - notably for user-level protection errors etc.
- Various minor fixes. I haven't made cdiffs (and I haven't gotten any
requests for them, so I probably never will), but they would be
pretty big.
Things that I didn't have time for:
- I wanted to rewrite the tty drivers to be more "streams-like" (ie not
an actual streams-implementation, but some of the ideas from
streams). I never got around to it: there was simply too much else
to do.
- I got a lot of patches, and some went in, others didn't. If you
think your patch was important, please re-send it relative to the new
version.
I'd like comments on the new system: performance / clarity of code etc.
0.97 should correct all known bugs (at least the ones I know about), but
I guess that's just wishful thinking.
Note that the dynamic buffer-code also handles differently-sized
buffers, but that the rest of the system (block device drivers,
filesystem code etc) cannot yet take advantage of this - there is still
some coding needed.
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Compiling linux 0.97
Message-ID: <1992Aug2.195402.29445@klaava.Helsinki.FI>
Date: 2 Aug 92 19:54:02 GMT
References: <YeT31Ie00WB30491Qd@andrew.cmu.edu>
Organization: University of Helsinki
Lines: 25
In article <YeT31Ie00WB30491Qd@andrew.cmu.edu> tj2n+@andrew.cmu.edu (Tao Jiang) writes:
>
>When I tried compiling linux 0.97, every thing worked fine, except that
>the operation speed is too slow compare to the previous version of
>linux.
I wrote a kernel profiling utility for this, and sent the patches
(small) and a user-level program to print out results (even smaller) to
the kernel mailing-list. If anybody sees this slow-down problem, and
tries out the profiling code, I'd be interested to have some sample
output.
If you aren't on the kernel list, I can make the patches available on
the net.
>This morning, I tried to compile it with DRAMDISK=512 defined in the Makefile,
>then error came out as:
My mistake: I never tried the ramdisk code in 0.97. The fix is
extremely simple (and is included in the above-mentioned profiling
diffs, I think): move the #include <linux/string.h> to be the last of
the include-statements. The reason is that <linux/string.h> wants some
standard types defined, and they get defined in the other include-files.
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: gid strangeness
Message-ID: <1992Aug2.221640.971@klaava.Helsinki.FI>
Date: 2 Aug 92 22:16:40 GMT
References: <1992Aug2.201320.9109@ifi.uio.no>
Organization: University of Helsinki
Lines: 33
In article <1992Aug2.201320.9109@ifi.uio.no> janl@ifi.uio.no (Jan Nicolai Langfeldt) writes:
>
>Hm, this is strange (and seems to happen only on my machine??), anyone
>seen anything similar?
>
>This happens with 0.96bpl2 and 0.96cpl2 (haven't tried 0.97 yet).
It's standard, and it happens on 0.97 too. Explanation to follow...
>I make a new group, 'test', give it number - say - 1000, ok, make a
>file, and chgrp it to test. 'ls -l' (or 'v') correctly shows 'test' in
>the group field. But not for long, suddenly (after 30 sec?) it changes
>to something else, gid = oldgid%512; it seems. Which is _very_
>strange. The most remarkable thing about my machine is that it has a
>aha1542 scsi disk controller.
It's not the controller, it's the minix filesystem. Minix uses only an
8-bit value for the gid value of a file - so although linux internally
(and the extended-fs) can handle real gids, the minix fs cannot. There
was nothing I could do about it - there simply isn't any room in the
minix inode on the disk. So when the inode is eventually read back,
only the low 8 bits are correct. The solution is either to use the
extended filesystem (which is still alpha, might change and might have
bugs) or only use gid's in the 0-255 range.
Another similar problem you can see with the minix filesystem is that
only the modify-time of a file can be stored on the disk (for the same
reason as the gid problem). So again, after the inode is read in from
disk, the other times are reset (to the same time as the modification
time). This problem is harder to see, and as programs seldom use the
other times it's not likely to be a problem.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Am I incorrect in assuming that my root partition can be an ext fs?
Message-ID: <1992Aug2.222619.1068@klaava.Helsinki.FI>
Date: 2 Aug 92 22:26:19 GMT
References: <CORYWEST.92Aug2144042@rio-grande.rice.edu>
Organization: University of Helsinki
Lines: 29
In article <CORYWEST.92Aug2144042@rio-grande.rice.edu> corywest@rice.edu (Cory West) writes:
> It seems that
>using bootlin and the 96c-pl2 kernel, I can't mount an extended
>partition as a root partition. I have the partition marked ok in
>my fstab and I can mount it if I boot from floppy, but I can't
>mount it as the root partition.
> Is this known and expected bahavior or should I fiddle
>with it some more? I am booting with bootlin.com from DOS using
>boot.sys as a multiplexer.
0.96c doesn't mount any other type of filesystem than the original minix
one as root - you have to get 0.97. 0.97 should be able to mount any
type of filesystem (you could even have a msdos fs as your
root-partition if you are evil and perverse - but don't tell anyone or
they'll whisper about you behind your back).
Note that I (surprise, surprise) haven't tested the new root-mounting
features. I don't see why it shouldn't work, but assuming it doesn't,
please mail me about it.
0.97 also finally cleans up the 'struct super_block' information - it's
no longer at all minix-specific. I got tired of hearing about it, and
when liljeber noticed problems with the msdos-fs in a pre-release I
decided to clean it up once and for all. So now the minix filesystem is
in no way special: but it happens to be well tested, and should have no
bugs (famous last words), so it's the way to go if you aren't too
adventurous.
Linus
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux 0.97 kernel compile problems
Keywords: 0.97 kernel
Message-ID: <1992Aug3.162747.25511@klaava.Helsinki.FI>
Date: 3 Aug 92 16:27:47 GMT
References: <1992Aug1.150838.11254@klaava.Helsinki.FI> <1992Aug3.062434.1600@uhura1.uucp>
Organization: University of Helsinki
Lines: 66
In article <1992Aug3.062434.1600@uhura1.uucp> bryan%uhura1@uunet.uu.net writes:
>>
>>There is also a kernel-compilation README (written by Lars Wirzenius),
>>as well as a COPYING (which is just a pointer to the GNU copyleft).
>
>Where are these files? They don't seem to be included in my copy
>of linux-0.97.tar.Z. If there's a kernel-compilation README, I need
>to read it, since I'm having kernel-compilation problems.
Lasu already sent out a copy of the README he wrote - and the COPYING
file was indeed only a pointer to the GNU copyleft, so you should get
that if you are interested in the copyright conditions.
[ My comment in the README that the symlink from /usr/include/linux to
/usr/src/linux/include/linux possibly wasn't needed was incorrect - you
do need the symlink ]
>>Changes in 0.97:
>>
>> - include-files have been moved around some more: there are still some
>> names that clash with the standard headers, but not many.
>
>There are only three files left under include/sys: kd.h, mman.h, and
>vt.h. Everything else that used to be under include/sys is now under
>include/linux. This means that all of the source you pull off of the
>net that includes files like <sys/types.h> and <sys/dirent.h> will
>require additional tweaking before compiling under Linux. What was
>wrong with leaving things under include/sys?
The problem with include/sys was that the kernel-specific things clashed
with the library things and vice versa. What 0.97 does is to move all
(or at least 99%) the kernel definitions into include/linux - while this
may result in problems for a while, the ides is that eventually (1.0 or
so), the user-level include-files use the kernel include-files for
kernel-specific things, and just add the library stuff.
So when there before was a <termios.h> in both /usr/include and
/usr/src/linux/include, I moved the kernel-specific things into
<linux/termios.h> - this contains the #defines and the data structures
the kernel uses (and thus the library functions need in some cases).
This allows me to add new #defines as new features are added, and if the
/usr/include/termios.h does a #include <linux/termios.h>, they are
automatically updated. In the above you can put files like errno.h,
signal.h etc instead of termios.h.
Note that the above isn't true yet: the kernel headers probably still
contain some things the user-level headers don't want and the user-level
headers don't include them yet, but I hope it will be true in a release
or two.
>(Side note: Not all of the Makefiles use "-I/usr/src/linux/include",
>if I recall correctly it was the SCSI code that tried to compile using
>my 0.96c header files under /usr/include.)
>
>Also, struct stat is now undefined. Not unnaturally, this means the
>kernel (with everything installed) won't compile. The file
>include/linux/stat.h defines struct old_stat and struct new_stat,
>but doesn't define either of them to be struct stat.
The kernel will compile without changes, so if you have problems, it's
due to the setup: make sure you have the /usr/include/linux symlink, and
a reasonably new 'make' that correctly inherits the CFLAGS etc. I'll
make the readme a bit more prominent next time (inside the actual
tar-file), so maybe kompiling will be easy by 0.98. Or maybe not.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Help! Install linux
Message-ID: <1992Aug3.173204.26700@klaava.Helsinki.FI>
Date: 3 Aug 92 17:32:04 GMT
References: <1992Aug3.164607.11322@njitgw.njit.edu>
Organization: University of Helsinki
Lines: 36
In article <1992Aug3.164607.11322@njitgw.njit.edu> shang@irss.uucp (shang wen-chung) writes:
>
>I've tried to install linux without success.
>The boot image(bootimage-0.97) goes fine and detect the system
>configuration correctly(SCSI HD, 2 FD, 2 serial line etc).
>But after I insert Root(rootimage-0.96) diskett, I got the following
>and system halt.
It seems the root diskette is not a valid minix filesystem - make sure
you used rawrite correctly on the diskette. It should be written to
disk the same way the boot-disk was made.
First linux tries to mount the disk using the minix filesystem - but
that fails, due to a bad magic number. The result is:
>magic match failed
So linux continues, and tries to mount the floppy using the extended fs.
Sadly, that try also fails for the same reason:
>magic match failed
Finally linux tries to mount the floppy as a msdos fs, and succeeds:
>MS-DOS FS Rel. alpha.6 FAT 12, conv=6, check=n
>No bmap suport
But as there is no bmap support for 512-byte sectors, you cannot execute
binaries from this filesystem. Even if there were any linux binaries on
it, which I doubt.
So either the floppy you give linux is a msdos floppy, or then the linux
msdos-recognition routines as bad, and the floppy doesn't contain
anything linux can use. Try to re-rawrite the root filesystem.
Linus
=============================
=============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 0.97 slowdown (Re: .97 (new buffer allocation code))
Keywords: new kernel
Message-ID: <1992Aug4.102113.14238@klaava.Helsinki.FI>
Date: 4 Aug 92 10:21:13 GMT
References: <1992Aug3.035648.7296@cs.tulane.edu> <5292@vtserf.cc.vt.edu> <1992Aug4.015452.26877@uniwa.uwa.edu.au>
Organization: University of Helsinki
Lines: 57
In article <1992Aug4.015452.26877@uniwa.uwa.edu.au> toivo@ucs.uwa.OZ.AU (Toivo Pedaste) writes:
>
>Well I did a test by compiling the 0.97 kernal (after a make clean) under both
>0.96 and 0.97. I have a 386-40 with 8meg memory and ran the test in an xterm
>on an otherwise idle machine (xclock was the only other X application running).
>
>0.96 kernal
> 730s real 448s user 127s system
>
>0.97 kernal
> 1521s real 449s user 166s system
>
>It took twice as long, I assume this was increased disk traffic (hence the
>higher system time). Is there a problem with dirty disk blocks filing
>up memory?
The problem with the 0.97 dynamic buffer cache is that when memory gets
tight, the buffer-cache is the first to go. Only after the buffer-cache
has been minimized does 0.97 start to swap. Thus under conditions where
there isn't too much free memory (running X and compiling), the buffer
cache is actually smaller than before - on a 8MB machine the buffers in
0.96 were about 1.3MB, but in 0.97 they shrink to about 300kB when
memory gets tight. And that means gcc effectively flushes the cache
every time it's run - thus the slowdown.
I've worked a bit on this (0.97 was the first version with dynamic
buffers, after all, so I didn't expect it all to be perfectly tuned),
and I've made the following changes to my new version:
- swapping and buffer-cache shrinking are interleaved: under extreme
circumstances linux still shrinks the buffers down to 300kB, but it
tries to swap out a bit before that.
- NRU (Not Recently Used) swapping algorithm with the idle-task helping
the swapping algorithm find good pages. It's not a full LRU, but it
does help to select the pages to be swapped.
With the original 0.97 I got a time of 32 minutes for a kernel build
under X11 (386-33, 8MB + 8MB swap, two xterms, syslog in a third xterm,
xclock and xeyes). After the latest kernel changes the time is down to
19 minutes: clearly the above helps a lot. The original 0.97 had buffer
usage around 300-800kB depending on how much memory the kernel make used
up, and the new kernel had about 900-1600kB buffers (and swapped out
un-needed pages more efficiently).
Note that in the above test I had actually less memory when testing the
new versions: the profiling-code in the new version eats up 300kB when
active. But also note that the above speedup (32 min -> 19 min) might
not be accurate on all machines - the changes migh not be as useful on
machines with a different setup or with programs that have different
memory/buffer behaviour.
I'll make patches to 0.97 available this evening or tomorrow - the
patches should also fix the 486 lockups that some people have
experienced.
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Problems with 0.97 kernel
Message-ID: <1992Aug4.165748.17556@klaava.Helsinki.FI>
Date: 4 Aug 92 16:57:48 GMT
References: <1992Aug4.153021.24129@dfv.rwth-aachen.de>
Organization: University of Helsinki
Lines: 19
In article <1992Aug4.153021.24129@dfv.rwth-aachen.de> mj@dfv.rwth-aachen.de (Martin Junius) writes:
>I just compiled the new 0.97 kernel and ran into the following
>problems:
>
>- Right after the floppy disk detect message it says:
> "floppy: unexpected interrupt"
>
>- When listing a tar archive on a floppy disk it says:
> "floppy: Over/Underrun - retrying". Retrying seems to work,
> the contents is listed correctly. Nevertheless these messages
> are annoying.
The problems aren't new - there is just some added debugging code in the
floppy driver (and in the harddisk driver as well - if it gets errors,
you are likely to see some debug-info printed out). The simple fix is
just to comment out all the printk's in the drivers - they aren't
needed, although they can be practical at times.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Signals are screwing up my tty reads.
Message-ID: <1992Aug4.192759.28334@klaava.Helsinki.FI>
Date: 4 Aug 92 19:27:59 GMT
References: <BsGKE1.Cp@Nyongwa.CAM.ORG>
Organization: University of Helsinki
Lines: 34
In article <BsGKE1.Cp@Nyongwa.CAM.ORG> steve@Nyongwa.CAM.ORG (Steve M. Robbins) writes:
>
>I have a program which reads in lines from a terminal using fgets().
>Normally this means I can use the backspace key for editing, and my program
>doesn't see this; it simply gets the edited line.
>
>Then, I wanted some daemons executed periodically, regardless of what the
>user is doing, so I used alarm(). All my SIGALRM handler does is call
>signal() and alarm() again. Suddenly line-editing no longer works.
>
>That is, it works between alarms, but as soon as the signal hits, I can no
>longer backspace over what is already in the buffer.
Sorry - it's a kernel bug that probably creapt in in 0.96c or so. Here
is a easy fix that should clear it up (I hope - untested as usual):
in linux/kernel/chr_drv/tty_io.c: function read_chan()
else if (L_CANON(tty))
wait_for_canon_input(tty);
should read:
else if (L_CANON(tty)) {
wait_for_canon_input(tty);
if (current->signal & ~current->blocked)
return -ERESTARTSYS;
}
The same bug exists in 0.97 (but no longer in my version).
I'd like to hear if the above clears up the problem.
Linus
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: .97 (new buffer allocation code)
Message-ID: <1992Aug5.120359.16381@klaava.Helsinki.FI>
Date: 5 Aug 92 12:03:59 GMT
References: <1992Aug4.145621.26421@crd.ge.com> <1992Aug5.023248.1639@uniwa.uwa.edu.au> <1992Aug5.102706.15668@colorado.edu>
Organization: University of Helsinki
Lines: 57
In article <1992Aug5.102706.15668@colorado.edu> drew@ophelia.cs.colorado.edu (Drew Eckhardt) writes:
>In article <1992Aug5.023248.1639@uniwa.uwa.edu.au> oreillym@tartarus.uwa.edu.au (Michael O'Reilly) writes:
>>
>>The 386 chip has a feature that lets you acomplish the same idea without
>>any fancy schemes like that. The basic idea is that when a page is
>>accessed for the first time, a bit is set in the page tables. WHen it is
>>written, a different bit is set.
The accessed bit will be used in the soon-to-be-made (I didn't get them
together yesterday, but I'll try again today) first patch to 0.97. It's
very practical, and didn't need any additional state information. While
the current routine isn't a real LRU (Least Recently Used) which needs
some actual calculations, it's NRU (Not Recently Used) which is a simple
approximation that can do with just the one bit that is already provided
by the hardware.
A closer approximation to LRU would be some aging mechanism (the 386
page tables even have room for a 3-bit wide aging or somthing like that
in the unused bits), and it might be worth implementing eventually.
>>So the way to do this is to clear all the bits, and then cycle through
>>doing.
>> is bit set?
>> yes -> clear it and go to next
>> no -> it can be swapped, swap it and move on.
This is similar to what the 0.97+patch1 algorithm does - it's simple,
and while it's not perfect it works relatively well. Or at least that's
the early indications from my tests. I won't be able to do exhaustive
tuning of the algorithms, so the patch1 algorithm might not be perfect.
We'll see.
>Yes and no. When determining what pages you want out, you want to
>deal with the hits for each incore page. There isn't a 1:1
>correspondance between a page in the page table, and a physical
>page. Instead, two or more processes may have the same page mapped,
>making the effect cumulative.
It's a bit more work to actually go through the pages and take this into
account, so I currently don't. But you are right: this is how it should
(and will) be done.
>Some one should see what times are for
>looking at every page in every dirty 4M range in every address
>space compared to what it takes to look at every page in physical
>memory, ie using a reverse hash function.
Actually, it's not a very time-critical check: it's done by the idle
task anyway (which is the reason I originally made task[0] special: it
just hasn't been used up till now). That way the machine does something
useful even when waiting for disk accesses etc. In patch1 the algorithm
just searches for non-accessed pages so that the system doesn't have to
do those calculations every time it wants to swap something out. It
should be relatively easy to enhance to do aging and check on the same
page being used by several different processes.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: =.97 patch1 available on nic
Message-ID: <1992Aug6.104732.16893@klaava.Helsinki.FI>
Date: 6 Aug 92 10:47:32 GMT
Organization: University of Helsinki
Lines: 26
It seems all connections to Finland are down (or at least some server is
acting up), so patch1 is available only on nic.funet.fi:
pub/OS/Linux/testing/Linus/linux-0.97.patch1.Z
I'll upload it to the other sites when I get a working ftp-connection.
Patch 1 is essentially a performance-release, but it also contains some
other patches: Ross Biro's tcp-ip stubs are there (but not the tcpip
subdirectory: alpha-testers should know where to find that), as are the
ext-fs superblock cleanups. The first header-file patch by hlu is also
in there.
The resulting patch is pretty big - it's also not as cleaned up as I'd
like it to be. The swapping/buffer-block handling heuristics are
better, but could still do with some tuning. Also, the idle task in
this version doesn't do very much: it will be expanded to do some more
page-table calculations.
I will be unable to hack on linux for a couple of weeks (I'll still
answer mails, read the newsgroup and fix bugs, but no heavy-duty
hacking) due to some "circumstances beyond my control". That probably
means that this patch is the last one for a while (three weeks) unless
some bad bugs show up.
Linus
==================
==================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Groff binary problems
Message-ID: <1992Aug8.104841.18911@klaava.Helsinki.FI>
Date: 8 Aug 92 10:48:41 GMT
References: <1992Aug7.123725.8121@vax.oxford.ac.uk>
Organization: University of Helsinki
Lines: 30
In article <1992Aug7.123725.8121@vax.oxford.ac.uk> tony@vax.oxford.ac.uk writes:
>Dear Linux Gurus,
> I'm having problems with the groff binaries from tsx. Having
>installed all the bits in /usr/local/ then moved them /usr (OK, so I got it
>wrong to start off with :-) I get the following error message when I try & read
>any of the man pages.
>
>using groff -man -T ascii /usr/man/man1/gtroff.1
>I get the following on /dev/tty (not stderr !) :-
> d9f2 fxxx not implemented
This is printed by the 387-emulator inside the kernel: the opcode 0xd9f2
means "fptan" which isn't emulated. Thus linux sends the process a
SIGILL, and groff prints
>& this on stderr :-
> groff: groff: Signal 4
(SIGILL == 4). As the first message is a kernel error message (and not
printed by the groff binary, it automatically goes to the currently
active virtual console (you can run groff in another VC, and still see
the message on the console you are currently using).
Either the groff binaries are statically linked with the hard-math
library (in which case you either have to recompile them or buy a 387)
or then your shared libraries are incorrectly set up (ie you have used
libhard.2.2.2 for /lib/libm.2.2.2 at installation instead of
libsoft.2.2.2).
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: patch1 blues
Message-ID: <1992Aug9.080811.6566@klaava.Helsinki.FI>
Date: 9 Aug 92 08:08:11 GMT
References: <1992Aug9.033453.21711@athena.mit.edu>
Organization: University of Helsinki
Lines: 37
In article <1992Aug9.033453.21711@athena.mit.edu> Epstein@DOCKMASTER.NCSC.MIL writes:
>
>To compile ps-0.97 (3 Aug newer version) I had to rm .depend make
>.depend (as stddef.h is in /usr/lib/gcc/...2.2.2/include/ vice
>/usr/include/ as per distribution .depend did a make and make install
>did a ps -U /usr/src/linux/tools/system /dev/swap this generated a new
>psdatabase HOWEVER get message symbol '_main_memory_start' not found
>trying to read invalid address
Make sure you have removed all the old object files: main_memory_start
no longer exists, and you should replace all occurences with just
"memory_start".
>I also get symbol '_paging_pages' not found trying to read invalid
>address when execute free [just like other people]
Rewrite free to use
memory_start = get_kword(k_addr("_memory_start"));
memory_end = get_kword(k_addr("_memory_end"));
paging_pages = (memory_end-memory_start)>>12;
These are constant (decided at boot-up), and will not change during a
linux session.
Other useful (dynamic) information is:
nr_buf = get_kword(k_addr("_nr_buffers"));
which tells you the current number of buffers in use, and
nr_free_pages = get_kword(k_addr("_nr_free_pages"));
which tells you how many free pages there are (this should be close to 0
as they should mostly be used for free buffers).
Linus
==================
==================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 0.97 (and pl1) memory use
Message-ID: <1992Aug10.073841.28831@klaava.Helsinki.FI>
Date: 10 Aug 92 07:38:41 GMT
Organization: University of Helsinki
Lines: 32
[ I already sent this out to the mailing-list, but here goes... ]
[ And yes, this is a /really/ silly bug, and I'm only glad nobody else
found it first :-]
There is a very silly bug in 0.97 (and pl1) which results in the dynamic
buffer cache being badly used: when the buffers are grown, only half of
the actual space reserved for them is used. The offending code is in
linux/fs/buffer.c, in the function grow_buffers():
There is a for-loop something like this:
for (i = 0 ; i+size <= 4096 ; i += size) {
.....
bh->b_size = size;
- i += size;
}
Note that i is updated twice (both at the end of the for-statement and
in the for-block) which results in only every other buffer-area being
actually used - half the available memory is simply ignored. The easy
bug-fix is to remove either of the "i += size" statements, and I'd
suggest you remove the latter one (marked with a "-" above).
So if somebody wondered why there were only 3000 buffers although "free"
reported that over 6MB was used, this is the reason. I didn't really
look at the values that free returned until today, so I never noticed
(Lars Wirzenius can tell about the time I "lost" 4MB or my 8MB memory
for a week due to a programming thinko like the above. I didn't notice
anything until I had to make him a 4MB version of the kernel :-)
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: unix clones for the pc abound
Message-ID: <1992Aug11.091230.141@klaava.Helsinki.FI>
Date: 11 Aug 92 09:12:30 GMT
References: <1992Aug10.174226.20085@daimi.aau.dk> <1992Aug10.214854.17763@unislc.uucp>
Organization: University of Helsinki
Lines: 34
In article <1992Aug10.214854.17763@unislc.uucp> erc@unislc.uucp (Ed Carp) writes:
>
>I see references to minix sprinkled through the kernel, through comp.os.linux,
>and through lots of the utilities. Some say that "such-and-such" utility was
>ported from minix, or was derived from minix. Here there be dragons...
Not really.. but read on.
>According to current copyright law in the U.S., a derivation of a copyrighted
>program (like the minix kernel, file system, or utilities) made without
>permission of the copyright holder is a violation of copyright law. So, either
>the linux kernel and utilities need to be 'sanitized', or someone's got to
>get assurances from Prentice-Hall that someone won't get sued for what is called
>"derivitive copyright infringement".
The minix kernel is well-documented ("OS design and implementation" by
Tanenbaum) and linux hasn't really got too much to do with minix anyway.
Although I have called linux a "minix-clone", it's no longer true in any
way, and never meant linux used very many ideas from minix. It just
looked more like minix-386 than any other OS. Note the past tense: now
even that isn't true (I'd say it's closer to either a "real" sysv or bsd
box than to minix).
There are a few things in the kernel that have been influenced by minix:
the original minix filesystem is the main one. Even that is a total
rewrite (and much better it is, if I may say so :-) and just keeps the
old physical layout on disk. Things like select() and VC's were also
originally influenced by their respective minix-patches (*).
Linus
(*) Note: these aren't even part of minix, but are available as patches
to minix written by others. Even if linux had used their code instead
of just their ideas, P-H has nothing to do with them.
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: root disk vs. mj disk, also hd.c patch
Message-ID: <1992Aug12.225636.5039@klaava.Helsinki.FI>
Date: 12 Aug 92 22:56:36 GMT
References: <1992Aug12.011334.17155@ultb.isc.rit.edu>
Organization: University of Helsinki
Lines: 37
In article <1992Aug12.011334.17155@ultb.isc.rit.edu> axi0349@ultb.isc.rit.edu (A.X. Ivasyuk ) writes:
>
>
>First of all, how do you get the executables to be so tiny on the root disk
>and the mj distribution? I can't get mine under 9K, even a 'hello, world'
>program. I'd like to be able to squeeze my 80MB drive to the max.
>It can't be just the -O flag on gcc.
By using shared libraries, and the "-N" flag, and stripping the result
you can often make trivial binaries that are much less than 9kB. BUT
they won't demand-load nor share pages, so it's worth it only if the
binary is truly small. Using "-N" on bigger binaries will result in bad
performance and memory waste when running it.
> [ Q two deleted ]
>Third, where is the one-line patch to hd.c (0.97) that everyone has been talking
>about? I think I missed it on the net. Could someone send it to me, please?
>(I already applied patch1 and the buffer patch, and it did improve performance
>noticeably, esp. patch1 - Thanks Linus!!!)
It's not to hd.c but to linux/fs/buffer.c - in the function
grow_buffers(). 0.97.pl1 has code that looks something like this:
for (i = 0 ; i+size <= 4096 ; i += size) {
bh = get_unused_buffer_head();
....
- i += size;
}
As you can see, 'i' is updated twice ('i += size' both inside the
for-loop and as the terminating expression), resulting in using only
half the available space in a page for buffers. The fix is to remove
the line I have marked with a "-". The above simple fix results in much
better free memory utilization, and a marked improvement in performance
under some circumstances.
Linus
=============================
=============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux history...
Message-ID: <1992Aug13.095315.18548@klaava.Helsinki.FI>
Date: 13 Aug 92 09:53:15 GMT
References: <1992Aug3.003404.6928@athena.mit.edu> <1992Aug3.165201.26088@klaava.Helsinki.FI> <1992Aug12.173725.21885@news.uni-stuttgart.de>
Organization: University of Helsinki
Lines: 14
In article <1992Aug12.173725.21885@news.uni-stuttgart.de> haible@izfm386i.fertigungstechnik.uni-stuttgart.de (Pascal Haible) writes:
>In article <1992Aug3.165201.26088@klaava.Helsinki.FI> wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
>[...]
>>
>>Linus is currently about 22 years and 7 months young. He speaks
> ^^^^^^^^
>That is already well (?) known - at least to kernel source readers
>-- or did he harcode in his girl friend's birth day?
>(hint: it's no use grep'ing for 1969 or 1970, it's a bit hidden)
No, it's my birthday, and I'm surprised anybody found it. I thought I
had hidden it well enough :-). And I'm not giving hints.
Linus
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux CDROM (Was stabilizing Linux)
Message-ID: <1992Aug13.095529.18687@klaava.Helsinki.FI>
Date: 13 Aug 92 09:55:29 GMT
References: <3284@ra.nrl.navy.mil> <1992Aug12.020246.22166@wimsey.bc.ca> <1992Aug12.164546.13304@crd.ge.com>
Organization: University of Helsinki
Lines: 18
In article <1992Aug12.164546.13304@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>In article <1992Aug12.020246.22166@wimsey.bc.ca>, bhenning@wimsey.bc.ca (Bill Henning) writes:
>| 3.75Gb/process would be great! I am not likely to need that ofcourse, nor will
>| I likely have a swap partition much greater than 10-20Mb, but fewer limitations
>| are allways welcome.
>|
>| Now if the number of processes are also increased from 64 to say 1024 that would
>| be great! (yes, I can see running out of 64 processes)
>
> I can see running out of 64 processes a lot faster than running out of
>64MB address space. I certainly am not running that much memory and
>swap.
The things are related: the 64 process maximum will be gone the same day
the 64MB limit is gone. It will just take a bit of coding on my part,
so don't expect it tomorrow..
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Why GNU cp is flakey under Linux
Message-ID: <1992Aug13.132338.8532@klaava.Helsinki.FI>
Date: 13 Aug 92 13:23:38 GMT
References: <1992Aug12.060338.24805@ennews.eas.asu.edu> <1992Aug12.063534.4178@muddcs.claremont.edu> <JRS.92Aug12190300@lepton.world.std.com>
Organization: University of Helsinki
Lines: 23
In article <JRS.92Aug12190300@lepton.world.std.com> jrs@world.std.com (Rick Sladkey) writes:
>
>An examination of the source code shows that GNU cp only performs this
>optimization if it thinks that the original file also had holes. The
>way GNU cp determines this is by comparing the number of blocks used
>with the actual file size. Furthermore, it only does this when it is
>compiled without ST_BLOCKS_MISSING defined. Note that the kernel is
>created by build and does not have any holes.
Yes, but GNU cp looks /only/ at the st_blocks field, and seems to ignore
st_blksize altogether, assuming it's a constant (usually 512). Or
that's what it looks like when just taking a quick look at the source.
And as the current linux kernel happens to use st_blksize = 1024 (and
thus also st_blocks is only half of what GNU cp seems to expect), the
test doesn't work very well. The result being that GNU cp creates holes
even if there were none in the original image.
I'll probably change the default st_blksize to 512 - easy enough to
change the math in linux/fs/stat.c, and it seems that's what some
programs expect. Programs which understand about st_blksize shouldn't
care one way or the other.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: executables in linux
Message-ID: <1992Aug13.133700.9139@klaava.Helsinki.FI>
Date: 13 Aug 92 13:37:00 GMT
References: <1992Aug12.225538.16085@usenet.ins.cwru.edu>
Organization: University of Helsinki
Lines: 23
In article <1992Aug12.225538.16085@usenet.ins.cwru.edu> mdr4@po.CWRU.Edu (Mark D. Rutherford) writes:
>
>I'm currently running linux .95. Several times now, I've FTP'd
>something, tar'd it to floppy, and then untar'd from linux,
>and tried to execute what I've untar'd. I get the message,
>"Cannot execute binary file" The directory listing for the file
>says that it's executable, and it's docs say it's executable.
>I'm sure it's something simple that I'm missing. Can anyone help?
While I have tried to keep each new kernel backwardsly compatible (ie
running most old binaries, excepting things like ps and in some cases
gdb), it's /not/ the case the other way around - binaries compiled with
a new compiler may not work on an older kernel. There have been several
changes in this direction: the header information changed somewhere
along the way (the old headers were still accepted, but old kernel
versions didn't accept the new headers) and new features (extended stat
structure etc) have made binaries unrunnable on older kernel versions.
So the answer is to upgrade your kernel: if possible all the way to
0.97.pl1 + the one-line patch due to performance reasons, but 0.96c or
similar should work very well for your needs.
Linus
================
================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: The Third Degree
Message-ID: <1992Aug14.205408.13958@klaava.Helsinki.FI>
Date: 14 Aug 92 20:54:08 GMT
References: <pz91Ht-g*8@atlantis.psu.edu> <1992Aug13.124939.16680@kth.se> <7gh1Hm#z&8@atlantis.psu.edu>
Organization: University of Helsinki
Lines: 28
In article <7gh1Hm#z&8@atlantis.psu.edu> bairstow@copland.psu.edu (Steven Bairstow) writes:
>In article <1992Aug13.124939.16680@kth.se> d88-jwn@blofeld.nada.kth.se (Johan W}hlin) writes:
>>bairstow@copland.psu.edu (Steven Bairstow) writes:
>>: ...
>>: - Has anyone noticed free inodes being left around? I think
>>: halt/shutdown is doing it. (This is what I was trying to figure
>>: out when it crashed.)
>>Yes I've been having this problem at least with reboot
>>
>
>Okay, so does anyone know where the code is for these programs so I can take
>a look at them, or who the author is?
I doubt it's either reboot or shutdown that results in the fsck errors:
what you are probably seeing is a normal result of the filesystem setup
under unix. I assume the problem is that fsck reports "inode XXX marked
in use: no file uses it" and "block XXXX marked in use: no file uses
it".
This can happen if you install a new version of a running program (like
'init') and reboot. The old 'init' is removed from the directory tree,
but as it's still in use, neither the inode nor the blocks are actually
reclaimed until the program is exited. And in many cases (like /bin/sh
or init or update), the program is never exited until the reboot has
happened. "fsck -a" should clear up the problem - or you should be more
careful when rebooting with "deleted" programs still running.
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux Standards (was: Stabilizing Linux)
Message-ID: <1992Aug16.073340.11418@klaava.Helsinki.FI>
Date: 16 Aug 92 07:33:40 GMT
References: <1992Aug6.125441.22427@klaava.Helsinki.FI> <Bt1u3u.3zv@world.std.com> <danielce.713926038@munagin>
Organization: University of Helsinki
Lines: 43
In article <danielce.713926038@munagin> danielce@mullian.ee.mu.OZ.AU (Daniel AMP Carosone) writes:
>
>May one presume that if Linus has any objections to what someone is
>doing with his work (and, by proxy, the work others have contributed)
>he will make them known and clear? If he does have some objection, and
>that is not heeded, he is free to change the terms of the License for
>later releases if he deems it necessary.
Well, I've answered this by email and earlier in the newsgroup, but I
guess it won't hurt to say it once more: I have no objection whatsoever
to any commercial use of linux that abides by the copyright. Not only
because I wouldn't have a legal leg to stand on, but simply because
there isn't any point in it. I'm not making any money off linux, so I
cannot lose anything by letting others do it - it's not as if they were
competing in the same market-place.
Also, if people sell linux, it certainly won't hurt the "free" status of
linux: it won't make all the free releases go away. So there isn't
really anything to get excited about - a commersial linux won't hurt the
linux users in the slightest, and might make linux available to people
that otherwise didn't have the possibility of getting it.
The earliest versions of linux had a more restrictive copyright: any
commercial activity was prohibited by it. That was mostly due to (a) an
overreaction to the price I had to pay for minix ($169 may not be much,
but it's still more than I can afford: I'm still paying monthly
installments on my machine) and (b) protection: linux wasn't well-known
then, and I didn't think it was ready for commercial use anyway.
(a) is silly, (b) went away with 0.12 - the copyright essentially
changed when I got the first query about selling linux (with just a
small delay to make sure there were no objections from people that had
made patches available. There weren't).
And as to the price: it doesn't really matter. If somebody wants to
make linux availabe for $ 995.95 ("special price just for you, amigo"),
I'd certainly be interested to hear how well it sells, but it won't
bother me. And bickering over whether $60 is too much is silly: people
buy it if they feel it's worth it. Actually, a nicely priced product
may sell better than a cheap one: it's illogical, but some people feel
that a product cannot be very good if it's cheap.
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: a patch for free in the ps-0.97 package
Message-ID: <1992Aug16.114537.9026@klaava.Helsinki.FI>
Date: 16 Aug 92 11:45:37 GMT
References: <SHARMAN.92Aug16012235@sharman.Software.Mitel.COM>
Organization: University of Helsinki
Lines: 14
Just in case anybody wonders: yes, the next patch will again break all
programs (well, most of them) that read kernel memory directly. In
fact, some things, notably the command line snooping that 'ps' does and
the page-counting ("ps m") will break totally: they have to be
rewritten, and will need kernel support. The reason is that /dev/mem is
no longer able to read the data in other processes: the memory
management has changed to use different page tables for each process.
I either have to implement some kind of /proc filesystem or support
some "get_ps_info()" system call - the get_ps_info() way is easier, but
a /proc fs might be a good idea and is more general. It will have to
wait for 0.98 or so, though: 0.97.pl2 won't have a good ps interface.
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Whining...I don't want to hack on the kernel
Message-ID: <1992Aug18.062556.6342@klaava.Helsinki.FI>
Date: 18 Aug 92 06:25:56 GMT
References: <1992Aug12.225538.16085@usenet.ins.cwru.edu> <1992Aug13.133700.9139@klaava.Helsinki.FI> <1992Aug18.011305.27223@access.usask.ca>
Organization: University of Helsinki
Lines: 20
In article <1992Aug18.011305.27223@access.usask.ca> dzubin@skorpio.usask.ca (Thomas Dzubin) writes:
>
>Sorry if this is sacreligious, but I DON'T WANT TO HACK THE KERNEL. It
>would be absolutely *wonderful* if someone (ANYONE!?) would put the
>binary of 0.97.pl1 somewhere FTP-able.
It's a valid gripe, and I'll probably make a binary available when I
release patch2 (this weekend). patch1 was a very hurried release: I
wouldn't have released it if it wasn't for the fact that I wanted to
hear comments about the speed-up (if any). As it turned out, patch1 is
perfectly ok (especially after the 1-line patch), and doesn't have any
more problems than any other release, but I wasn't sure when I made it.
There still seems to be some problems with 0.97.pl1: the buffer-cache
corruption is the worst one. I haven't seen it myself, and it seems to
be a SCSI problem, but I'm not sure. I'll probably try the test-program
somebody posted if I can find the disk-space for it. I doubt the
problem will be fixed by patch2: especially if I'm unable to see it.
Linus
==================
==================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: A question about Kernel system call mechanism
Keywords: linux, kernel, system call
Message-ID: <1992Aug20.122051.24901@klaava.Helsinki.FI>
Date: 20 Aug 92 12:20:51 GMT
References: <1992Aug19.174117.21233@ramsey.cs.laurentian.ca>
Organization: University of Helsinki
Lines: 102
In article <1992Aug19.174117.21233@ramsey.cs.laurentian.ca> ron@ramsey.cs.laurentian.ca (Ron Prediger [Velociraptor]) writes:
>I am relatively new to Linux and have been examining the kernel source.
>
>1) Does anyone know how linux passes parameters from the user process to the
>kernel service routine ? Below is what I think is happening and where I
>am confused.
>
>It appears that system calls are handled using interrupt or trap gates
>resident in the Interrupt descriptor table (IDT). From reading the Intel
>386 ref. manual I understand that a stack switch occurs automatically when
>a less privileged process accesses a gate for a more privileged subroutine.
Correct so far...
>What I can't see is how the kernel service routine gets the system call
>parameters (ie. addresses, etc) from the user process. Is there code
>somewhere which copies these parameters from the original (level 3) stack to
>the more privileged (level 0) stack ? If linux had used call gates to
>implement system calls, the parameters would automatically be copied to the
>privileged routine's stack by the 386. (This automatic
>copy of parameters does not occur when referencing interrupt/trap gates.)
I didn't like system call gates: they are too complicated for my taste
(besides, you have to know how many arguments to copy, or have a
specific system call gate for each type of argument: maybe not a bad
idea, but...). Anyway, things are easier than you make them out to be:
the arguments are simply passed in the normal registers.
Passing arguments in the registers allows you 6 (32-bit) direct
arguments (not counting %eax, which is used to tell which system call
you want handled), and more if you simply set up a pointer to a block in
user space. And the beauty of it all is that they are automatically put
on the stack in as arguments to the system calls when the registers are
saved - see the file linux/kernel/sys_call.S, which saves all the
necessary state information. It's the simplest and fastest way I could
find: linux doesn't even save the state in some special task-structure
like other unices seem to do, but just leaves the regs on the stack,
ready for popping when the process returns from the interrupt.
>2) It appears that Linux is making use of segment registers (FS,GS) and the
>LDT/GDT to transfer the actual data (ie. from a read system call) between
>user and kernel address spaces. Is this observation correct ?
Actually, only %fs is used: it points to the user-space segment when in
a system call. Thus linux never needs to check any bounds when copying
from/to user space: it's automatically handled by the hardware. The
get_fs_XXX() and put_fs_XXX() (XXX=byte, word, long) inline functions
can be used to transfer bytes from/to user space, and memcpy_tofs() or
memcpy_fromfs() can be used to move bigger blocks between kernel and
user segments.
What happens at a system call is roughly:
user space:
- load the arguments into registers (%eax contains the system call
index, %ebx... contain the parameters)
- do an "int $0x80", moving to kernel mode:
kernel space:
- clear the direction-flag, as gcc assumes this
- save the system call number: a negative number means the interrupt
was caused by a hardware IRQ or trap.
- save all the segment registers
- save %eax (which happens to be the same number we saved earlier if
this is a normal system call)
- save the other registers: they automatically form the stack frame for
the system call.
- call the appropriate system call handler by indexing the appropriate
table with %eax.
The handler does it's stuff - it /can/ change the stack frame if it
wants to, and thus return information in any registers it wants to, but
that is really discouraged, and all system calls currently just return
their result in %eax as part of their normal return.
- check if there were any signals, and change the return stack (both in
kernel and user space) appropriately if so, invoking the signal
handler instead of returning directly.
- pop all the saved registers, and do an iret, returning to user mode.
While the system call runs, the %ds and %es registers point to kernel
data space, and %fs points to user space. But the system calls may
change %fs for their own needs: for example symbolic links result in
changing %fs to kernel space for a while as the name is parsed directly
from the kernel buffers instead of from user space etc.
Note that normal faults/traps and IRQ's do essentially exactly the same,
except for "fast" IRQ's, which just save a minimal amount of information
and don't do the signal checking (used by things like the serial
handlers). Also, they naturally haven't got any "system call number",
but have their own routine that is called after the stack is set up.
As to the GDT: the GDT contains just two normal segment entries: GDT[1]
is the kernel code segment descriptor, and GDT[2] is the kernel data
descriptor. The rest of the global descriptor table is filled with TSS
and LDT descriptors. The local descriptor tables normally contain just
the user-space code/data descriptors in LDT[1] and LDT[2], but it's
flexible enough to be extended if something wants to have more segments
in user space (I think the xenix emulator uses this, although I haven't
looked at the code yet).
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Paying off Linus' PC (was: Linux Standards)
Message-ID: <1992Aug21.065950.8463@klaava.Helsinki.FI>
Date: 21 Aug 92 06:59:50 GMT
References: <1992Aug16.073340.11418@klaava.Helsinki.FI> <1992Aug18.070709.16015@trl.oz.au> <1992Aug19.162616.3357@news.acns.nwu.edu>
Organization: University of Helsinki
Lines: 39
I hate to follow up to a thread that might actually be profitable for
me, but I felt I had to clarify a few points - especially if there are
new linux users out there reading the thread.
If people feel they want to send me money (indirectly or directly) as a
token of appreciation, that's very much ok by me (surprise, surprise),
but a token of appreciation is all it is going to be. Yes, I'll be able
to pay off my machine more quickly or even get a bigger harddisk or
whatever, but sending me money won't get you any better service - this
is definitely not a "registration fee" or anything like that.
The above just means that (a) even if you don't send any money I won't
mind in the least that you use linux, and when I answer questions etc I
won't check if you sent me money first. And (b) even if you sent me
money, any features you propose/want will get no extra priority. In
fact, trying to make me feel guilty over money ("after all, I paid you
$20 for this") is likely to get the exact opposite reaction.
Finally, I won't give any guarantees of what the money will be used for:
if you add some kind of message giving preferences ("use it to pay off
your computer"), I'll naturally follow them within reasonable limits,
but I might just use them to pay off my "beer&pizza"-debts (*), which
might be against your religion or whatever.
So, the result of all this? If somebody thought I was despairing about
my monthly payments, that's not true, and frankly, I'll get the computer
paid off even if nobody sends me a cent, even if it might take me a bit
longer. Also, there are others that have contributed to linux, and I
won't give them anything (not because I'm a selfish bastard, but simply
due to practical reasons).
If any of the above reasons made you decide I don't really need the
money, I just ask you not to mail me about it. I /don't/ want to know
about any money I might have gotten, but didn't.
Linus
(*) Yes, beer is reasonably costly over here in Finland, but no, my
debts aren't really that big. Quite small, in fact, considering..
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: A technical question on CONTEXT (TASK) SWITCHING by the Kernel
Keywords: task switch, context switch, task state segment, kernel
Message-ID: <1992Aug21.072548.10633@klaava.Helsinki.FI>
Date: 21 Aug 92 07:25:48 GMT
References: <1992Aug20.164928.24749@ramsey.cs.laurentian.ca>
Organization: University of Helsinki
Lines: 80
In article <1992Aug20.164928.24749@ramsey.cs.laurentian.ca> ron@ramsey.cs.laurentian.ca (Ron Prediger [Velociraptor]) writes:
>Here is another technical question about the Linux kernel. Context
>switching in particular.
Ok, more answers...
> #define switch_to(n) {\
> struct {long a,b;} __tmp;\
This just fools gcc to get 8 bytes of space on the stack, so that we
don't have to get them anywhere else..
> __asm__("cmpl %%ecx,_current\n\t"\
> "je 1f\n\t
%ecx is set up with the task we want to switch to when we enter the
inline assembly statement, so this is obviosuly testing whether we are
trying to switch to the current task, in which case nothing is done.
Besides being an obvious optimization, I don't think the 386 allows a
tss-jump to the current task (but not having my books around me, I can't
check).
> "movw %%dx, %1\n\t"\
This just moves %dx (which contains the tss-selector) into the word at
__tmp+4. So ___tmp looks like this:
__tmp+0: undefined long
__tmp+4: tss-selector word
__tmp+6: undefined word
> "xchgl %%ecx,_current\n\t"\
This exchanges %ecx and 'current' - %ecx will contain the task we are
now executing in, and 'current' will contain the task we are just about
to jump to.
> "ljmp %0\n\t"\
This does the actual task switch: we do an indirect long-jump to __tmp.
This is also the reason we updated just the word at __tmp+4: a long jump
to a new tss-selector will ignore all other values. It will
automatically jump to the place indicated by the tss segment.
> "cmpl %%ecx,_last_task_used_math\n\t"\
Yes, this looks illogical: we just did an unconditional jump, and this
should never be reached. Right? Wrong. The ljmp will return once some
other task does it's own ljmp to this task. Now %ecx contains the
current task, so we check if this is the task that used the math
coprocessor last...
> "jne 1f\n\t"\
> "clts\n"\
...in which case we can clear the TS flag, giving better
math-performance. Due to these three lines, linux never saves math state
unnecessarily.
> "1:"\
> "::"m" (*&__tmp.a),"m" (*&__tmp.b), \
This just sets up %0 - pointing to '__tmp', and %1, pointing to
'__tmp+4'.
> "d" (_TSS(n)), "c" ((long) task[n]) \
%dx contains the tss-descriptor for the task we want to switch to, and
%ecx contains the task-pointer of the task we want to switch to.
> :"cx");\
And this just tells gcc that %ecx is changed by the inline-asm.
That's it: 8 lines of assembly does the linux context switch with
math-state optimizations. Note that newer sources should have a cli-sti
pair around the "xchg %%ecx,_current ; ljmp %0", so that 'current' is
always up-to-date, even when running under interrupts.
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: shared libs - can everyone be happy with this?
Message-ID: <1992Aug21.075538.12640@klaava.Helsinki.FI>
Date: 21 Aug 92 07:55:38 GMT
References: <1992Aug17.152210.23427@riacs.edu> <1992Aug18.023010.6841@colorado.edu> <TED.92Aug20103404@pylos.nmsu.edu>
Organization: University of Helsinki
Lines: 27
In article <TED.92Aug20103404@pylos.nmsu.edu> ted@nmsu.edu writes:
>
>writable code segments or executable data segments are _very_
>important to programs that would like to do dynamic loading.
>
>of these two options, the second is preferable.
Right now, linux accepts both: early versions of linux didn't allow
executable data-segments (the code segment was only as long as indicated
by the executable header), but I changed that as gcc-2 actually assumes
data space is executable (it can build small functions on the stack).
Another reason was actually to get 'crashme' to run: without an
executable data-segment crashme won't run at all (without
modifications). And while it might sound weird to change the kernel to
/help/ crashme, that's what I did. After all, the idea of crashme is to
test whether a system is stable, and if crashme fails for the silly
reason that it cannot execute the code it has just set up, it's not
anything to brag about. The fact that crashme /still/ seems to fail
despite being able to try, is a good thing (tm).
Writable code might go away eventually: there is no longer any good
reason for it now that the standard library should be well-behaved. But
I'm not in any hurry about it: if somebody /wants/ to write
self-modifying code, maybe it should be permissible. I don't dislike
goto's either.
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: problem compiling 0.97pl1.5 with gcc2.2.2d
Message-ID: <1992Aug22.200046.25400@klaava.Helsinki.FI>
Date: 22 Aug 92 20:00:46 GMT
References: <1992Aug22.164625.772@rock.concert.net>
Organization: University of Helsinki
Lines: 35
In article <1992Aug22.164625.772@rock.concert.net> cole@concert.net (Derrick C. Cole) writes:
>
>Using the 96c bootimage, and after installing gcc2.2.2d and the 0.97 source
>and patches, I am able to compile the kernel sans problem.
>
>However, after the unix socket init, I get an unstoppable list of
>
>[ ...lots of error stuff deleted... ]
>kernel panic: no free inodes in mem
>[ ...lots of error stuff deleted... ]
Sounds like the infamous problem with shoelace and a kernel image with
holes in it. The fix is either not to use shoelace, or make sure
/vmunix (or whatever you call it) has no holes. The latter can be done
by using "cat /usr/src/linux/Image > /vmunix" instead of using 'cp' (or
you can use 'dd' or any number of other things).
While I'm orating, I might as well mention that 0.97.pl2 will be out
tomorrow: it contains mostly the memory management rewrite, but also has
some bigger vfs patches (mostly with symbolic links, but also some
general fixes). The changes will mostly not be seen on a user level:
some error-codes have been corrected, and linux gives each task 3GB
address space, but normal programs won't notice anything. The memory
management cleanup also allowed a clean vm86-mode, so that's in.
pl2 is relative to (unpatched) pl1, so people who have applied the
1-line fix will get patch errors.
Also, while I haven't been totally out of touch, I've not answered all
my mail (or answered very tersely) the last weeks, due to work. I also
haven't had time to check out all the patches I've gotten etc. I should
have more time for linux the upcoming weeks, so hopefully I'll try to
catch up a bit.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: linux-0.97 patchlevel 2
Message-ID: <1992Aug23.221741.6989@klaava.Helsinki.FI>
Date: 23 Aug 92 22:17:41 GMT
Organization: University of Helsinki
Lines: 56
As promised, 0.97.pl2 is out today (well, over here it's already
tomorrow, so I guess I'm 35 minutes late. Naughty, naughty). Right
now, the patch (and full source for those that don't like to patch up
the system) is available at "nic.funet.fi: pub/OS/Linux/testing/Linus",
but I'll try to put it on some other sites as well if I'm able and
energetic enough. Probably tomorrow - together with a binary for those
that aren't willing to comple the kernel on their own.
0.97.2 has mostly my mm/fs patches, along with some relatively minor
diffs by others (including file locking by Doug Evans). User-level
changes are minor: but the mm has changed a lot, and the vfs routines
have been changed to keep track of the error-messages a bit better.
Also, the vfs-interface to "follow_link()" changed slightly: people who
are making filesystems should look at the changes (but they are
relatively minor, and shouldn't result in any problems - both the
extended fs and minix fs needed just a simple change in their respective
symlink.c files).
The mm changes /might/ lower performance slightly, as the paging TLB's
are now flushed at every task-switch due to the new system, but I doubt
it's noticeable. The other performance changes (dynamic buffers etc) in
0.97(.pl1) should overshadow that particular problem.
I hope this release means that these kinds of low-level rewrites aren't
needed for a while: the last couple of releases have changed some very
fundamental things. Nothing seems to have suffered too badly, but I'd
be happier if it all got tested more thoroughly. Anyway, discounting
the ps/free etc suite of programs, everything I have tried has worked
flawlessly despite the big kernel changes.
I'm still worried about the reports about messed-up buffers, but have
been unable to reproduce the problem, and nobody has so far
disillusioned me about my guess that it's a problem with the SCSI code
(which at least gives me an excuse for not doing anything about it :-).
Other problems include at least one report of spontaneous re-booting,
which is totally inexplicable, so I'm blaming hardware once more until I
can get better data on the thing.
As to patches sent by others: 0.97.2 contains very little of that kind
of code. I've been too busy either working, or implementing my own
changes that I have simply ignored them for the most part. Remind me
(or resend them relative to the new kernel) if you have a patch that is
still needed.
There is one new system call: 'vm86(struct vm86_struct * info)'. It's
not ready for general use yet - it works, but will probably need some
tweaking before being practical. But supporting a virtual 86 mode was
so easy after the mm rewrite that I felt it was worth implementing: the
vm86 code is less than 50 lines of C right now.
Linus
PS. The bright spot of the week goes to "The Oxford Beer Trolls" - all
UK inhabitants should probably be locked into some (big) mental
institution and TOBT should probably have a wing of their own, but
thanks to them linux can now call itself "beerware" :-)
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Suid/sgid
Message-ID: <1992Aug26.075014.9277@klaava.Helsinki.FI>
Date: 26 Aug 92 07:50:14 GMT
References: <1992Aug25.230907.10073@utstat.uucp>
Organization: University of Helsinki
Lines: 21
In article <1992Aug25.230907.10073@utstat.uucp> rafal@utstat.uucp (Rafal Kustra (summer student)) writes:
>Perhaps this should be posted to other group
>but I only have time to read this one + some local
>ones ;).
>OK, here is the beef.
>Either I don't understand the concept of suid/sgid
>(**very** possible) or there is something wrong.
>Say root creates a script like follows:
> cat $*
>and sets it suid.
>Now normal user could cat any r--.....
>file with it, right?
You aren't misunderstanding the concepts, but suid only works on actual
binary executables, not shell (or any other kind of) scripts. The
reasons are security, security and security. It /may/ be possible to
make a suid shell script secure, but it's so easy to make them a
(non-obvious) security hazard that it's definitely a bad idea to allow
them. So linux ignores the suid/sgid bits when executing scripts.
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.97p2
Message-ID: <1992Aug28.230526.7253@klaava.Helsinki.FI>
Date: 28 Aug 92 23:05:26 GMT
References: <1992Aug28.123817.20350@csd.uch.gr>
Organization: University of Helsinki
Lines: 50
In article <1992Aug28.123817.20350@csd.uch.gr> kermits@pasifae.cc.uch.gr (Aggelos Keromyths) writes:
>I just tried 0.97p2 from the disk drive and it seemed to me a lot
> slower than 0.97 (no patch at all!!!)....When i did an `ls` it
> started reading the drive,then stopped,then again reading and finally
> presented the directory...but it was SLOW....
>What could be the problem ?
Hmm. I'd like to hear more about the problem - especially if you can
pinpoint it more closely (ie having used 0.97, 0.97.pl1 and now pl2) to
a specific patch. As most people said 0.97.pl1 was fast, I'm assuming
it's specific to patch2, but I'd like to have some confirmation before I
start looking into the problem.
If it's patch2, the problem is probably the changed mm code: having
different page tables for each process might be costlier than I thought.
The old (pre-0.97.pl2) mm was very simple and efficient - TLB flushes
happened reasonably seldom. With the new mm, the TLB gets flushed at
every task-switch (not due to any explicit flushing code, but just
because that's how the 386 does things when tasks have different cr3's).
I can optimize things a bit - it's reasonably easy to fake away some of
the TLB flushes by simply forcing the idle task to always use the same
cr3 as the last task did (as the idle task runs only in kernel memory,
and kernel memory is the same for all processes). So, I'd be interested
to hear if this simple patch speeds linux up at all:
- in linux/kernel/sched.c: schedule() - change
cli();
switch_to(next);
to
cli();
+ if (!next)
+ task[0]->tss.cr3 = current->tss.cr3
switch_to(next);
ie just add the one if-statement.
If the above makes a difference, I'd like to hear it, and I'll put it in
the standard kernel.
I'd also like to know what kind of machines the slowdown is most
noticeable on: assuming it's the mm changes I'd guess it's non-cached
machines (possibly SX-machines) for which a TLB flush will result in a
noticeable performance-loss. So if you notice a slowdown, please mail
me that kind of info as well.
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: VM86
Message-ID: <1992Aug29.091200.16019@klaava.Helsinki.FI>
Date: 29 Aug 92 09:12:00 GMT
References: <1992Aug29.065940.1256@athena.mit.edu>
Organization: University of Helsinki
Lines: 68
In article <1992Aug29.065940.1256@athena.mit.edu> hammond@kwhpc.caseng.com (Kevin W. Hammond) writes:
>I see with patch 2 there is a vm86.h file and I recall seeing some mention
>of Linux supporting a virtual 8086 mode. Is this true and, if so, how does
>one use the virtual 8086 driver?
Yes, 0.97.pl2 has support for a vm86 mode: note that this is /not/ the
same as a DOS emulator, but it can be used for that. The interface
looks like this:
void vm86(struct vm86_struct * info);
where vm86_struct is defined in linux/vm86.h, and currently looks like
this:
struct vm86_struct {
struct vm86_regs regs;
unsigned long flag;
}
The flag value is not currently used, and I assume some additional
fields will be added eventually (a page dirty map for efficient screen
updating etc), but the above is enough for a simple DOS emulator.
The vm86() system call is pretty simple: it loads the registers with the
values in the 'regs' structure, and starts executing in vm86 mode. It
will return to protected mode when a signal happens: when this happens
the vm86 state is saved in the info structure and the signal handler is
executed in normal 32-bit mode. The signal handlers can then use the
vm86_struct information to see what is going on, and correcting any
errors etc.
A simple DOS emulator would look like this (pseudo-code):
global struct vm86_struct info;
main()
{
set up the DOS memory image at 0 - 1MB
set up SIGSEGV and SIGILL etc signal handlers
set up the initial regs etc in 'info'
while (1)
vm86(&info);
}
SIGILL_handler()
{
read 'info' to see why we got a SIGILL - if we can
emulate it, update 'info' and return, else exit
}
SIGSEGV_handler()
{
see SIGILL
}
SIGALRM_handler()
{
check the screen memory in the vm86 box, and update the real
screen every now and then. Do any other regular house-keeping
fn's.
}
Note that all this happens in user mode - the kernel doesn't really do
anything special about vm86 mode. And as the emulator and vm86 code is
in the same process, is should be possible to make it all relatively
efficient.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Beginners problems
Message-ID: <1992Aug29.195511.23402@klaava.Helsinki.FI>
Date: 29 Aug 92 19:55:11 GMT
References: <1564@lysator.liu.se>
Organization: University of Helsinki
Lines: 57
In article <1564@lysator.liu.se> lien@lysator.liu.se (Jan Lien) writes:
>Problems encountered with Linux 0.97 - help appreciated.
>I have succesfully booted Linux on my pc, root system on hard drive.
>However there are some serious problems, here listed in order of
>percieved severity.
>
>- mtools does not recognize my G: and H: ms-dos logical drives on my
> extended partition. I get the error ENOENT for these disks, but
> they are in the proper table, as I can use C-D-E-F disks. Fdisk
> finds them as hda9 and hda10.
> Is this an built in constraint in Linux? I got error messages when
> I tried to use hda10 for a linux disk.
This is probably a limit in the rootdisks - I think the /dev/hdaX
entries only go as far as /dev/hda8. The fix is very simple: just
create the needed special files with mknod:
# mknod /dev/hda9 b 3 9
# mknod /dev/hda10 b 3 10
etc. By doing a "ls -l /dev/hd*" you see the device numbers, and the
setup should be pretty obvious when reading them.
>- emacs over a serial port (/dev/ttys1 or /dev/ttys2) writes in the
> mode line. Is there an error in termcap (vt100 terminal), or is
> the number of lines set incorrectly? If it is number of lines,
> where (and how) do I change them?
The problem is the default number of rows that linux uses: I have
stupidly set the value to 25 instead of the normal 24 for a vt100
terminal. The fix should once more be very simple: do a
# stty rows 24 columns 80
or
# eval `resize`
on the line before staring up.
>- where do I find information on what all the options to a command
> does? (I can find out that there are -abcdefgh... to a command,
> but what do they do?)
The man-pages for most GNU things are in the sources - for some binaries
(like fsck) no man page is available, and you have to read the actual
source files.
>- while logged in on a serial port (/dev/ttys1 or /dev/ttys2) and
> doing a cat or cp to /dev/tty, if I repeatedly press ctrl-C
> I get logged out.
This is usually a mark of a bad compile of the shell, but I haven't seen
it (but I use my own port of most relatively simple things). Don't know
of any simple fix.
Linus
==================
==================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Will SLIP/PPP support be available soon?
Message-ID: <1992Aug30.222112.14969@klaava.Helsinki.FI>
Date: 30 Aug 92 22:21:12 GMT
References: <9208302107.AA27751@cue.bc.ca>
Organization: University of Helsinki
Lines: 14
In article <9208302107.AA27751@cue.bc.ca> tdzubin@cue.bc.ca (Thomas Dzubin) writes:
>
>Is the TCP/IP stuff slated to be included in the next 'standard' Kernel
>release (Linus?).
Yes, the tcp/ip subdirectory will be part of the next major release (ie
0.98), although I won't have it compiled into the standard bootimage.
People who need it can recompile the kernel easily enough, and it's not
essential for the rest of the system.
Linus
PS. And yes, 'ps', 'free' etc will be slightly broken once more, but
not too badly this time.
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: HD interrupts and IDE
Message-ID: <1992Aug30.221612.14848@klaava.Helsinki.FI>
Date: 30 Aug 92 22:16:12 GMT
References: <1992Aug30.161030.5898@ncsu.edu>
Organization: University of Helsinki
Lines: 26
In article <1992Aug30.161030.5898@ncsu.edu> big@garfield.catt.ncsu.edu (Alan Porter) writes:
>
>
>I have been getting the infamous "Unexpected HD interrupt" messages
>whenever I do anything that requires a lot of disk activity (like tar,
>or worse yet, rebuilding the kernel).
>
>Even more annoying, I also get the "HD timeout", the 4 second wait, and
>then the "HD-controller reset".
>
>First, my system:
>386-40, IDE drive (KLOC KL3120, 115 MB), 4 MB RAM, 60 MB Minix FS, 5 MB swap.
This is "normal" for kalok drives: they give these unexpected interrupts
for some unfathomable reason. I actually have a OEM manual for kalok
drives (thanks to whoever got it to me), but it doesn't mention this
kind of behaviour, so I guess it's a "undocumented feature", ie bug.
The problem can be at least partly fixed by defining HD_DELAY in hd.c to
something other than 0 - try different values until it disappears
(starting with 1000 or something like that). It should get rid of at
least most of the errors, as the problem seems to be that the drive
isn't ready to accept a new command even though it indicates it is in
the status register.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Broken symlinks ?? (followup)
Message-ID: <1992Aug31.125539.5089@klaava.Helsinki.FI>
Date: 31 Aug 92 12:55:39 GMT
References: <1992Aug31.054608.2405@athena.mit.edu>
Organization: University of Helsinki
Lines: 21
In article <1992Aug31.054608.2405@athena.mit.edu> hammond@kwhpc.caseng.com writes:
>
>0.97 seems to fail if the actual executable is owned by root and has a mode of
>711 (or actually, any mode that does not include read permission). If the executable
>is owned by a non-root user, things do work correctly. Is this some sort of security
>measure in the kernel? Maybe I (or anyone else) should look at the kernel code to
>find out!
It's a bug in 0.97.pl2, but I've corrected it already, and pl3 (out next
weekend) will take care of it. The problem is that the current symlink
code wants read-permissions to the file the symlink points to, due to me
not thinking all the changes through when I updated to the better
namei() routines in patch2.
The interim solution while waiting for patch3 is to make all executables
or directories that are pointed to by symlinks world readable, and the
problem should go away. In case somebody wants to correct in in their
kernel, the place to look at is fs/open.c and fs/namei.c - you should
move the permission check from open_namei() to sys_open().
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: .97 kernel and root disk/probs with swapping
Message-ID: <1992Aug31.194716.16232@klaava.Helsinki.FI>
Date: 31 Aug 92 19:47:16 GMT
References: <6026@pdxgate.UUCP> <1992Aug31.024052.12351@cc.umontreal.ca>
Organization: University of Helsinki
Lines: 76
In article <1992Aug31.024052.12351@cc.umontreal.ca> duperval@ERE.UMontreal.CA (Duperval Laurent) writes:
>In article <6026@pdxgate.UUCP> moyerg@rigel.cs.pdx.edu (gary a moyer) writes:
>>I am now in the process of getting the kernel to compile however I am getting
>>some strange results. I am using a 2M swap file (NOT partition). I get
>>some errors during swaps like:
>>rw_swap: bad swapfile
>>
>>This occurs during compilation using gcc 2.2.2d with 4M RAM and 2M swap.
>>Any ideas? Thanks.
>
>I have similar problems with kernel compilation. I have 4M of memory and 8M
>swap space. When compiling I get an out of memory, out of swap space error.
>I'm running all the stuff that was on mcc-interim 0.96c (gcc 2.2.2, kernel
>0.96c).
The "bad swapfile" problem is most usually due to (wait for it) a bad
swapfile. Hmm. Maybe I should use cryptic numbers and give something
like "ERR192SWP" instead - but that would also mean I'd have to write
some documentation on the thing. Not good.
Anyway, to make a swapfile, it's not enough to just run "mkswap" -
mkswap just writes the swap signature and some bad-page info. You
actually have to create the swapfile with the correct size and without
holes first. How you create the swapfile is totally up to you, but the
normal thing to do is:
# dd if=/dev/zero of=swapfile bs=1024 count=XXXX
where XXXX is the size of the file in kilobytes. You now have an empty
file which is exactly XXXX blocks long. To mark it swappable, you then
run mkswap on it and sync:
# mkswap swapfile XXXX
# sync
You now have a swapfile that is ready to be used: swapping is then
enabled with
# swapon swapfile
It's normal to put the 'swapon' command in your /etc/rc.local or
whatever - but you can do it by hand at each reboot if you want to.
Note that if you use a swap-paritition, you obviosuly don't have to
create it first with "dd" or whetever: just make sure you have a good
partition free, and run "mkswap" on it. With swap partitions, it's
generally a good idea to map out bad spots (or you'll get all sorts of
nasty errors), so use the "-c" switch for this:
# mkswap -c /dev/hdXX XXXX
# sync
and
# swapon /dev/hdXX
Swapping from a partition is a lot faster than swapping from a file, but
creating a file is easier, and it's easier to remove or resize.
>I never encountered this prblem before and I thought I had plenty of room.
>BTW, if anyone is interested, my make fails on chr_drv/tty_io.c when I have
>one console open and on chr_drv/console.c when two consoles are open.
>
>Also, what are these 'put_tty_queue' declarations disagree about 'inline'
>errors I get. What do they mean and could they be a hint as to what is going
>wrong?
the "disagree about inline" message is arguably a gcc bug: it's an
uncommonly stupid warning, and I don't know why gcc prints it. It's
probably easy to get rid of by just putting a "inline" before the
prototype in include/linux/tty.h, but I'm too lazy to even test it out.
The way gcc inline (nonstatic, nonexternal) functions work, it's totally
illogical to ask it to be prototyped that way. I don't mind too much:
as long as my only gripes with gcc are of this type, I'm happy.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: getting "bogus do_no_page"; strange vi behavior
Message-ID: <1992Aug31.195805.16530@klaava.Helsinki.FI>
Date: 31 Aug 92 19:58:05 GMT
References: <1992Aug31.145123.20915@novell.com>
Organization: University of Helsinki
Lines: 24
In article <1992Aug31.145123.20915@novell.com> bboerner@novdpd.uucp (Brendan B. Boerner) writes:
>Hello, using Linux 0.97 and later 0.92 Pl#2, when compiling (among
>other things) on a (386/16 w/a tad under 5MB of RAM) I start getting
>spurious "bogus do_no_page" messages. These don't appear on my
>girlfriend's computer (486/33 w/8MB RAM).
The "bogus do_no_page" error seems to happen on older 386 chips: they
sometimes give spurious page-faults. The linux approach is just to
print the warning message and return: it seems to work, and the 386 will
happily do the page translation correctly the next time around. You
should be able to safely uncomment the printk() that prints the message:
especially if linux doesn't seem to mind, and you have no other
problems.
>Also, after upgrading to 0.97, I noticed that vi has been acting
>funny. While inserting into a line, it starts adding spaces. Using ^L
>will redraw the screen and show that the spaces really don't exist.
I think this is due to an incorrect /etc/termcap: the correct fix is
naturally just to dump 'vi' and start using some emacs-like editor :-)
If that isn't possible, try getting a new termcap from a newer rootdisk,
and the problem should hopefully disappear.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: GNU kids on the block? (sorry... couldn't resist)
Message-ID: <1992Aug31.200513.16637@klaava.Helsinki.FI>
Date: 31 Aug 92 20:05:13 GMT
References: <la0fp9INNe3@appserv.Eng.Sun.COM> <1992Aug31.185733.21037@hpmcaa.mcm.hp.com>
Organization: University of Helsinki
Lines: 23
In article <1992Aug31.185733.21037@hpmcaa.mcm.hp.com> bryanf@hpmcaa (Bryan Ford) writes:
>lm@slovax.Eng.Sun.COM (Larry McVoy) writes:
>> steve@hacker.UUCP (Stephen M. Youndt) writes:
>> : but I feel very strongly about one thing [...]
>> : (according to rumors :-), and that's reloadable device drivers.
>> : It just seems that the micro kernel people are the only ones doing it.
>>
>> SunOS has had loadable device drivers, system calls, and functions (I'm
>> not sure what you use the last one for but there it is) since SunOS 4.1.
>
>So has AmigaDOS, since 1.0. :-)
I've got a month or two to implement them yet (evil grin) - I'm not even
up to 0.98, and I'm seriously thinking about it. No promises, but it
looks simple enough (after all: why do you think I gave the kernel a 1GB
virtual address space when changing the mm...)
Linus
PS. Seriously: it will take a few releases to get anything working -
0.98 may have some support for it, but these things take time: 0.12 had
the kernel support for shared libraries, but only now are they getting
mature.
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Swap files (was: Re: .97 kernel and root disk/probs with swapping)
Message-ID: <1992Sep1.083154.5064@klaava.Helsinki.FI>
Date: 1 Sep 92 08:31:54 GMT
References: <1992Aug31.024052.12351@cc.umontreal.ca> <1992Aug31.194716.16232@klaava.Helsinki.FI> <bjl.715328078@freyr>
Organization: University of Helsinki
Lines: 54
In article <bjl.715328078@freyr> B.J.Lippolt@research.ptt.nl writes:
>
>On the subject of swapping.
>
>Would it be possible to implement a scheme (a la SunOS) where you can
>'add' swap files to the swap space? E.g. I have a 8Mb swap partition, and
>when I need more (which happens once in a while) I just create a swap
>file and add it to my 8 Mb swap space. Would this be a minor (i.e. I
>can do it myself) or a major change?
It wouldn't be too hard: right now swap-map numbers are 31-bit entities,
and it would be pretty easy to use the high 7 bits to be indexes to the
swap-file, while keeping the low 24 bits as the page-in-swapfile index.
The changes would be pretty minimal, although it would need a thorough
understanding of the swapping setup. It's an interesting thought: I
might implement it myself some time when I have nothing better to do.
Anyway - if you are interested to implement it yourself, the thing to do
is roughly:
- change all the swap-file related variables to be arrays, and add a
"nr_swapfiles" variable that keeps count of how many are in use. The
variables are rougly:
swap_bitmap, swap_lockmap, swap_device, swap_file
as well as some optimization values (lowest_bit, highest_bit) used so
that the routines wouldn't have to go through the full bitmap all the
time.
It would look a bit like this:
struct swap_info {
struct inode * swap_file;
int swap_device;
char * swap_bitmap;
char * swap_lockmap;
int lowest_bit, int highest_bit;
} swap_info[MAX_SWAPFILES];
int nr_swapfiles = 0;
- change the "get_swap_page()", "rw_swap_page()" and "swap_free()"
functions to understand the high bits of the swap block-nr, and
naturally the sys_swapon() system call to enable it all.
The changes shouldn't actually be more than a couple of lines in each
place, and it shouldn't be more than a couple of hours work - assuming
you understand the code.
On the other hand, I've been looking into a "sys_swapoff()" system call
(which needs a bit more thought: you have to make sure the swapfile
isn't used by anything), and I might implement the aboev at the same
time. No promises.
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: io.h/iopl
Message-ID: <1992Sep1.152745.17949@klaava.Helsinki.FI>
Date: 1 Sep 92 15:27:45 GMT
References: <1992Sep1.123648.18859@cbnewsd.cb.att.com>
Organization: University of Helsinki
Lines: 50
In article <1992Sep1.123648.18859@cbnewsd.cb.att.com> asmith@cbnewsd.cb.att.com (arthur.c.smith) writes:
>Hi,
> I have been working on an S3 driver for X and have an 80X86 asm program
>under dos that will setup the S3 chip correctly (and uses the enhanced
>rectangle fill command to clear the screen 8-)). I am trying to port this
>over to Linux. I am having two problems. 1) In trying to use sys_iopl()
>I tried to write it as _syscall1(void,110,int,3) and include unistd.h
>(and __LIBRARY__ defined). I get an error when this compiles. Is there
>a better way to do this?
That is not how you are supposed to use the _syscallX macros - they just
build the system call for you. You are supposed to do it like this:
static _syscall1(int,iopl,int,level) /* note: no semicolon */
main()
{
if (iopl(3)) {
perror("iopl");
exit(1);
}
....
}
Also note that gcc-2.2.2d should have the iopl() system call in the
standard library, so the _syscall1() things isn't needed at all if you
use the new gcc.
Then a word of warning: using iopl() is /not/ recommended. If you do
some stupid programming error, there is simply too big a chance to mess
up: disabling interrupts will totally hose the machine (which is why
iopl() only works for the super-user, but even the super-user should be
careful about it).
If you can get by by using the ioperm() system call (which only works
for the 0-0x3ff range of IO ports), use that instead. ioperm() gives
only access to a selected subset of the IO ports, and doesn't mean you
can disable interrupts etc.
> 2) Trying to port to C: When I include /usr/src/linux/
>include/asm/io.h and use outb I get undefined _outb referenced in .text. In
>looking at io.h it appears as if the outb function is defined as extern but
>is also defined in io.h???
Sounds weird: the inb() and outb() functions should work fine as long as
you have included <asm/io.h>. You might want to make sure you have
either "-finline-functions" or "-O" on the gcc command-line: I haven't
checked what gcc thinks about inline-functions without those.
Linus
============================
============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Swap files (was: Re: .97 kernel and root disk/probs with swapping)
Message-ID: <1992Sep1.153412.18136@klaava.Helsinki.FI>
Date: 1 Sep 92 15:34:12 GMT
References: <1992Aug31.194716.16232@klaava.Helsinki.FI> <bjl.715328078@freyr> <1992Sep1.083154.5064@klaava.Helsinki.FI>
Organization: University of Helsinki
Lines: 22
In article <1992Sep1.083154.5064@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>In article <bjl.715328078@freyr> B.J.Lippolt@research.ptt.nl writes:
>>
>>On the subject of swapping.
>>
>>Would it be possible to implement a scheme (a la SunOS) where you can
>>'add' swap files to the swap space? E.g. I have a 8Mb swap partition, and
>>when I need more (which happens once in a while) I just create a swap
>>file and add it to my 8 Mb swap space. Would this be a minor (i.e. I
>>can do it myself) or a major change?
>
>It wouldn't be too hard: right now swap-map numbers are 31-bit entities,
[ explanation on how to implement it deleted ]
Ok, don't implement this: I already did it, and the (minor, as promised)
changes will be in the next patch. I'm currently running linux with two
different swapfiles, and it accepts up to 8 different files (and up to
128 after changing a single #define and recompiling). I haven't
implemented "swapoff()" yet, but I guess that too will be implemented
today.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: symlinks in 0.97pl2
Message-ID: <1992Sep3.103546.11747@klaava.Helsinki.FI>
Date: 3 Sep 92 10:35:46 GMT
References: <1992Aug31.020059.21670@athena.mit.edu> <1992Sep2.205903.6121@julian.uwo.ca>
Organization: University of Helsinki
Lines: 27
In article <1992Sep2.205903.6121@julian.uwo.ca> klode@syslab.csd.uwo.ca (Claude Morin) writes:
>SunOS 4.1.1 allows the following:
>
> r-x--x--x ... ff*
> lrwxrwxrwx ... bob -> ff*
>
> rubble[400] % cat bob
> #!/bin/sh -
> echo hello
> rubble[401] % ./ff
> hello
> rubble[402] % ./bob
> hello
>
>So I guess that linux is 'broken'. Perhaps linux is displaying correct POSIX
>behaviour...
No, linux isn't "posixly" correct: it's a bug that creapt in with the
changed symlink code in 0.97.pl2. The pl2 behaviour is to require
read-permissions of any target of a symlink, which is definitely wrong -
but I already corrected it, and pl3 (out Saturday) gets it right. pl3
also contains the multiple swap-file and swapoff() code, as well as
various other minor fixes. If pl3 is ok, I'll probably release it later
as 0.98 with no essential changes: just adding the tcpip directory and
possibly other "secondary" code.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Benchmarking under Linux (was Re: New 486 Suggestions?
Message-ID: <1992Sep4.100706.12473@klaava.Helsinki.FI>
Date: 4 Sep 92 10:07:06 GMT
References: <1992Aug31.180211.24228@news.acns.nwu.edu> <1992Aug31.210041.21832@novell.com> <1992Sep2.175417.11302@pool.info.sunyit.edu>
Organization: University of Helsinki
Lines: 28
In article <1992Aug31.210041.21832@novell.com> bboerner@novell.com (Brendan B. Boerner) writes:
>
>This has me wondering: does anyone have any benchmarking or performance
>metric programs for Linux? I've got a 386/16Mhz w/a tad under 5MB of
>RAM and it takes me somewhere between 3-4hours to build the kernel. On
>my girlfriend's machine, a 486/33 w/8MB RAM, it takes under 10
>minutes. I'd like to get an idea of where I could improve
>performance.
RAM space is the first thing to look for: gcc eats memory like mad, and
swapping is slow especially with the older kernels. I hope my changes
to the swap-algorithms in 0.97.pl3 will help people with slow machines:
it does seem to help even on my 8MB machine (kernel compilation time
when running X+some xterms fell from 18 minutes to 15). The main change
was to use a page-used counter instead of just a swp bitmap, which
allows fork() to be speeded up /a lot/ when swapping.
But processor speed can be very important under linux: not just for the
obvious user-level speedup, but due to better response to disk-drive
interrupts and the like. Faster machines may simply read the disk at
the full 1:1 interleave - with slower systems, it's possible that the HD
driver doesn't keep up, and you get the dreaded 1-block/rotation
syndrome, which really hurts when swapping. This problem is probably
especially notable on 386SX machines: the 386 interrupt handling is
inherently slow, but if the memory badwidth is further reduced by the
16-bit bus, interrupt response is probably ever worse.
Linus
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 0.97 patchlevel 3 available
Message-ID: <1992Sep5.184606.11361@klaava.Helsinki.FI>
Date: 5 Sep 92 18:46:06 GMT
Organization: University of Helsinki
Lines: 110
[ This was already sent to the NORMAL mailing-list, and this is
essentially the same announcement. ]
Well, 0.97.pl3 is available both as full source (linux-0.97.3.tar.Z) and
as a context diff (linux-0.97.patch3.Z) on nic.funet.fi, in the normal
directory (pob/OS/Linux/testing/Linus). It seems some line is once more
down on the way to the US, so I haven't uploaded it to tsx-11 yet.
Also, I haven't been able to use the pub/Linux/Linus directory on
sunsite (it dies on me when I try to send the group password), so I
don't know when sunsite will get the new release.
Patch3 is almost 100kB even compressed, as there were quite big changes
in the mm and minix fs. No major new features: there are two new system
calls: swapoff(const char * swapfile) and wait4(), and linux accepts
several swap-files, but the rest of the thing is mostly bug-fixes or
simply rewrites.
Major changes:
- new swap-page handling: linux no longer uses just one bit to keep
track of used swap-space, but a counter for each swap-page. This
allows processes to share swap-pages after a fork(), and should
result in /major/ performance increases on machines with less memory.
I've seen better performance even with 8MB - I wouldn't be surprised
if 4MB machines would re-compile the kernel noticeably faster under
pl3. I'd be interested to hear numbers.
- The low 1MB memory that isn't used directly by the kernel is now
swappable memory, instead of being hardcoded for buffer cache. The
patches for this were originally by tytso, and I expanded on it a bit
more. This might also help better performance on 2-4MB machines.
Note that this does /not/ mean that you can use 1M machines for
linux: linux still needs some extended memory.
- the dosfs has been upgraded to dosfs.8 - patches by almesber.
- I edited the minix fs pretty heavily to remove a couple of race-
conditions. The same races still exist in the extended fs, as I
didn't have time to edit that yet. The minix-fs took precedence as I
know that better, and extfs isn't "official" yet anyway.
other changes:
- the mouse-driver now handles both Logitech (minor = 0) and PS/2
(minor = 1) busmice.
- there is a proc-fs for access to user memory/files etc.
- better support for the tcp/ip patches (but see below...)
- corrected symlink and /dev/[k]mem behaviour
- Lars Wirzenius' README (with minimal comments by me) and the GNU
COPYING notice are now part of the normal kernel setup, and can be
found in the tar-archive.
- the floppy ioctl() to get the FD parameters no longer requires root
priviledges. Thus, the msdos emulator runs even for a normal user.
Some comments on patchlevel 3:
mm:
The swap-page handling resulted in a reduction of swap-file (or
partition) size to a maximum of 16MB per file. It's nothing inherent to
the code, but it eased some algorithms, so I didn't bother coding around
it. After all, 16MB is enough for most people, and if you want more,
you can have up to 128 swapfiles of 16MB each. If I get enough
hate-mail about it, I might just try to find the energy to correct it.
Maybe.
Bigger swapfiles will still work, but linux will take advantage of only
the low 16MB. Also, there is no nifty logic to try to optimize the
usage of the swap-files: pages are simply allocated from one swap-file
until it fills up, and then the next swap-file is used.
The memory management changes break ps/free once more, but not very
much. Also, I changed the load-average counting, so 'w' also needs
slight editing. On the other hand, I made '/dev/kmem' mmap()able, and
'ps' and 'free' should be edited to take advantage of that: it should
result in much faster operation, as well as possibly using less real
memory.
fs:
The fs changes should remove at least two races - the races don't happen
very often, but they were theoretically possible, and might be the
reason for some fs corruption problems that have been reported. The
changes are related to the use of bmap() - the bmap interface doesn't
really lend itself to some things that it was used for. Re-writing
internal fs-functions not to use bmap not only should have removed any
races, but also actually resulted in cleaner code.
The proc-fs code isn't too beautiful, and I'll probably leave it out
from 0.98 unless I can make it loadable. We'll see. If anybody wants
to use it, you can do something like
# mount -t proc /dev/ram /proc
Instead of /dev/ram you can use any block device - it's not used, and is
only a dummy as the proc-fs doesn't actually use any external device.
(but note that the device is still marked as mounted, so you cannot
mount it for anything else).
kernel/mm/lib:
The TCP/IP patches are also essentially in 0.97.pl3 - not the full
TCP/IP directory, only the patches to the main kernel. NOTE!! I don't
like the 'grab_malloc_pages()' function, so I left that out, and added a
GFP_ATOMIC priority to get_free_page() that should be used instead. I
hope this will be used (Ross?), as it's a lot cleaner.
Also, I hope the tcp/ip people will clean up malloc() so that it doesn't
panic instead of returning NULL etc. Ugly, ugly. This is related to
the get_free_page(GFP_ATOMIC) changes, and I'd like to have patches as
soon as possible - tcp/ip won't be part of the standard kernel until
that can be cleaned up.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.97 patchlevel 3 available
Message-ID: <1992Sep7.080727.22080@klaava.Helsinki.FI>
Date: 7 Sep 92 08:07:27 GMT
References: <1992Sep5.184606.11361@klaava.Helsinki.FI> <1992Sep6.174044.28957@mo.hobby.nl>
Organization: University of Helsinki
Lines: 26
In article <1992Sep6.174044.28957@mo.hobby.nl> hans@mo.hobby.nl (Hans Oey) writes:
>
>Sure, 16 Mb is enough. Jeez, why would people ever need
>more then 640 Kb? Swap partitions give far better
>performance. Should we use up to 128 partitions?
>Please remove this limitation on Linux. Would a beer or
>two help you to find the energy?
Actually, beer-drinking doesn't seem to help programming very much :-)
And as people have been very concerned about the 16MB limit - don't
panic. It's not inherent to anything like the DOS 640kB limit, and is
there just because it was a bit easier to code that way - correcting it
later won't break anything. So while this version and the next may have
this limitation, it will go away (cleanly) - I just have to code some
more.
In case anybody is wondering why there is a 16MB limit in the pl3 code,
it's very simple: I use a character array to store the swap-page-counts,
and that array just happens to be 4096 bytes long, as that's the biggest
easily allocable unit of memory in the current kernel. So I just
allocate 4096 bytes: 4096 swap-page-counters = 16MB swapspace. So the
only thing that I have to do to allow bigger swapfiles is to allocate
more memory - SMOP, but irritating and boring.
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Can't get 0.97pl3 to boot
Message-ID: <1992Sep7.081220.22423@klaava.Helsinki.FI>
Date: 7 Sep 92 08:12:20 GMT
References: <715841111snx@temple.demon.co.uk.demon.co.uk>
Organization: University of Helsinki
Lines: 23
In article <715841111snx@temple.demon.co.uk.demon.co.uk> pdc@temple.demon.co.uk.demon.co.uk (Piers Cawley) writes:
>
>But: I just pulled the new 0.97pl3 sources down from nic.funet.fi, hacked
>keyboard.c so that # and @ are in the right place and compiled. Thus far, no
>problems. However, when I copied /usr/src/linux/Image to /etc, did the rdev
>incantation over it and rebooted, I got the following message:
[ deleted ]
I'd be much happier if people using shoelace would try booting from a
floppy (or using lilo) - right now I always suspect a problem with
shoelace when I see these kinds of messages. Shoelace isn't supposed to
be used any more: please get lilo instead.
Shoelace has several problems:
- it doesn't handle holes in the Image file gracefully
- nobody seems to remember if there are any limits to the size shoelace
can load.
- shoelace cannot handle anything else but the minix fs.
So please try booting from a floppy, and resubmit the problem-report if
it still won't work.
Linus
============================
============================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: HD-timeout problems
Message-ID: <1992Sep6.091302.29969@klaava.Helsinki.FI>
Date: 6 Sep 92 09:13:02 GMT
References: <1992Sep5.201920.3244@afterlife.ncsc.mil>
Organization: University of Helsinki
Lines: 41
In article <1992Sep5.201920.3244@afterlife.ncsc.mil> swaliff@afterlife.ncsc.mil (Steve Aliff) writes:
>I'm experiencing enough "HD-Timeout/HD-controller reset" messages to
>have become frustrated (irritated?) with it. This occurs both with
>the MCC release (.97p2) and the SLS release (.96c I believe). The
>SLS kernel has the "static int reset = 0" code in it. (I built a new
>kernel just for kicks. And The problem occurred BEFORE and after I
>built the kernel. ;-) ) The problem doesn't appear to happen when I
>crank the clock back from 33MHz to 10Mhz. Needless to say, that's
>not an acceptable solution.
There are two things you can do to alleviate the problem. In order of
"preferability":
- check that your IO bus runs at 8MHz or lower. Having a 11MHz bus
seems to be pretty standard setup, but it's unsafe, and running
beyond specs. Check out your extended setup (press DEL on bootup for
AMI bios or whatever) - it's usually something like
Bus speed: CLK/2, CLK/3, CLK/4, CLK/5.
for a 33MHz machine, CLK/4 should give an acceptable 8.25MHz clock for
the IO bus. Your setup may also allow you to set ISA bus waitstates,
and editing this field may help. Read the motherboard manual if you
have one.
- edit the HD_DELAY value in kernel/blk_drv/hd.c. It is normally 0,
but setting it to some other value may help some buggy
controllers/drives. Test out different values, starting off with
1000, and try to find the lowest value you can get that works.
And finally, you can also try changing the HD controller card: a cheap
multi-io card may have some weird problem that doesn't show up under
DOS. If you can swap cards with someone just for testing purposes, and
that fixes the problem, getting a new controller card may be the
solution. But as this may be impossible (or just too expensive, even
though IDE controllers should be cheap), try out the above first.
All the above fixes have helped - it may not in your case, but it's
worth checking out.
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux 0.97p2 compatibility, GCC/SHAREDLIBS/JUMPTABLES.
Message-ID: <1992Sep6.185549.8454@klaava.Helsinki.FI>
Date: 6 Sep 92 18:55:49 GMT
References: <k=pnyqq.genie@netcom.com> <BALASUB.92Sep6121304@organ.cis.ohio-state.edu>
Organization: University of Helsinki
Lines: 71
In article <BALASUB.92Sep6121304@organ.cis.ohio-state.edu> balasub@organ.cis.ohio-state.edu (Krishna Balasubramanian) writes:
>
>GCC main releases, the corresponding linux version and some
>distributions that use this version of GCC are approximately
>as follows: (see the GCC FAQ to find out more).
>
>1) 2.11c, May 19 linux 0.96 x11v1.0
>2) 2.2.2, Jun 27 > linux 0.96ap4 rootdisk-0.97, x11v1.1, SLS, MCC-0.96c.
>3) 2.2.2d Aug 12 > linux 0.97p1 rootdisk-0.97.1 , MCC-0.97p2
>
>There will probably be a new GCC version with X11 in a week or so.
Right. And in case anybody is nervous about the inverse relation (ie
running old programs under new kernel releases), that should always work
*barring bugs or "undocumented features"*. So all old binaries will
generally work on new versions of the kernel.
The ptrace() interface was changed in 0.95 - but that was before gdb was
publically available, and it broke no binaries.
Other than things like that, all "nice" programs should work from one
release to another. They may not be able to use new features (VFS etc),
but they should work as well as they ever did. Note that new gcc
versions, new features etc have made a recompile a good idea, but not
strictly necessary - I still use the following programs:
-rwxr-xr-x 1 torvalds uucp 9491 Aug 19 1991 /bin/sync
-rwxr-xr-x 1 torvalds uucp 20640 Aug 21 1991 /usr/bin/dhrystone
-rwxr-xr-x 1 torvalds uucp 72091 Sep 8 1991 /usr/bin/egrep
-rwxr-xr-x 1 torvalds uucp 72090 Sep 8 1991 /usr/bin/grep
-rwxr-xr-x 1 torvalds uucp 31176 Sep 13 1991 /usr/bin/od
and they work perfectly ok even though some of them are probably from
before the 0.01 release.
"non-nice" programs include the 'ps'-suite of programs that muck around
with kernel memory, and simply buggy programs that may work on older
releases. An example of the latter is anything that accesses memory that
it hasn't first allocated with 'brk()'. Those programs worked fine in
0.96, but 0.96b (I think) adopted the standard unix practice of sending
such a program a SIGSEGV.
Similarly, some 'mount' binaries won't work under 0.97.pl2 even though
they worked on pl1. They did a no-no that just happened to go unchecked
in the older kernel. Another example of a program that didn't work with
pl2 was "lilo" - it depended on the stat() system call returning the
same buffer-size as used internally in the kernel, which no longer is
necessarily true (and just happened to work in earlier versions).
Of course, there are also kernel bugs that can result in a binary not
working under a new release: this happened in pl2 with the symlink code
and to a lesser extent with /dev/mem. I generally try to fix that kind
of thing as fast as possible: pl3 has these corrected.
So if you are using an old kernel in the fear that things won't work
with a newer version, you should probably at least try to upgrade: the
chances are everything works fine even if you don't have the latest
user-level binaries. On the other hand, it may be only prudent to wait
a while until a release has shown itself to be stable - people who are
happy with their current kernel don't necessarily need to upgrade (but
don't be surprised if some new binary doesn't work).
Linus
PS. None of the above means that future versions of linux will
necessarily be 100% compatible. If I decide it's worth it, I might
break all old programs by doing something in a more clever way. But
I'll document it very clearly if I'm aware of the problem. And it's not
very likely: after all I'm running the same programs as everybody else
(and older versions than some), and I don't feel any terrible urges to
recompile everything.
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Progress report?
Message-ID: <1992Sep7.142246.22137@klaava.Helsinki.FI>
Date: 7 Sep 92 14:22:46 GMT
References: <1992Sep7.125312.20025@wam.umd.edu>
Organization: University of Helsinki
Lines: 79
In article <1992Sep7.125312.20025@wam.umd.edu> joel@wam.umd.edu (Joel M. Hoffman) writes:
>I've been away for the Summer, and have missed most of c.o.l. Could
>someone who's been following it for the the Summer please let me know
>what I've missed. My last kernel is 0.96.
Get 0.97.pl4 - it seems to be stable (knock wood: I haven't gotten any
reports on it yet), and fixes a lot of things. Out today, and available
at "nic.funet.fi" "pub/OS/Linux/testing/Linus".
You might want to reinstall from scratch: the mcc or SLS releases look
promising, although I naturally haven't tried either. They get you the
current compiler and good versions of most of the standard tools
(although you should probably get the new 'mount' package that fixes a
lot of bugs. Good work - I liked it)
>Specifically, is there a DOS emulator yet? Have the VM86 patches at
>least made it into the standard distribution? Have my code-page
>patches made it into the standard distribution?
The original VM86 patches never made it into the standard kernel, but I
implemented a very similar vm86() system call when rewriting the mm (it
got very easy after that), and yes, there is a working msdos emulator
available. But it's very simple (but fun: having DOS running under X11
in an xterm sure gives a professional feeling to the system :-), and
gives up for any program that tries to do anything more complicated, so
it's not useable for "real" work yet. You can boot up a msdos floppy on
it, and play around with "dir" etc, but that's about it (has anybody
tried early versions of turbo-pascal? they should work on almost
anything). Expect to hack on it before it's actually practical.
As to any code-page patches, I have to admit I can't remember them, so I
don't know if the current kernel does something similar.
>My GCC library is marked lib92.04.06. Is there a new one? If I get
>the new one, do I have to recompile all of my programs? Do we have
>jump-tables yet so that when a newer library comes out programs won't
>have to be recompiled?
Wait a week or so for the next release, which hopefully will use the
"final" jump-table setup (as well as having new X11 libraries etc).
After that, the libraries should finally be stable (sure...) - the
libraries already seem to work well, but they were changed to take
advantage of the new mm setup, and the new version is in testing right
now.
lib92.04.06 is totally obsolete, and I doubt it can be found anywhere
any more (I think I removed it from my disk a month ago, and most people
probably never even saw it).
>Is there anything else I would want to know about?
Not really: 0.97.pl4 has some new features (/many/ new features when
compared to 0.96) and should be faster/better etc, but the best way to
find out is probably just to get the new system. Anything older than
0.96c.pl2 should probably not be used any more: 0.96c.pl2 is pretty
stable, but I do believe 0.97.pl4 is better in almost all respects (it's
bigger, but uses memory better, so you should actually have more free
mem anyway). It's not too much tested, so I'm still keeping my fingers
crossed, but even if there are bugs it's sure to be better than
unpatched 0.96 which could be crashed just by catting some binaries to
the VC's.
Tcp/ip is getting there, and I expect it to be in the standard kernel in
a couple of weeks. The extended filesystem is still in a bit of a flux,
but most other things should hopefully have calmed down now (I can't
guarantee all the minix-fs bugs are gone, but I feel pretty good about
it all). I'm finally getting happy about the kernel: I have no major
project going on any more. Naturally there are "details" like loadable
device drivers, shmem(), mmap() etc that are interesting, and need to be
implemented one way or another, but I've been feeling content since
0.97.2, and while I had to fix a couple of bugs in it, I still think 1.0
can be reality without any more major rewrites.
Linus
(Note: "feeling good about it" does NOT mean I'll stop working on it
after 1.0 - I distinctly remember feeling good about version 0.12, and
things have certainly changed since then. I just enjoy feeling good
about my code, so I try to do it as much as possible :-)
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Progress report?
Message-ID: <1992Sep7.173250.14016@klaava.Helsinki.FI>
Date: 7 Sep 92 17:32:50 GMT
References: <1992Sep7.125312.20025@wam.umd.edu> <1992Sep7.142246.22137@klaava.Helsinki.FI> <1992Sep7.163715.8229@fwi.uva.nl>
Organization: University of Helsinki
Lines: 29
In article <1992Sep7.163715.8229@fwi.uva.nl> vesseur@fwi.uva.nl (Joep Vesseur) writes:
>torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>
>>Get 0.97.pl4 - it seems to be stable (knock wood: I haven't gotten any
>>reports on it yet),
>
>c'mone linus, give us a break: it's out for only 2hrs 40mins :-)
"ONLY" 2hrs 40mins? WHAT? How much time do you want to thoroughly test
out a new version? Lazy bums (*)
Actually, the pl4 changes are small enough that I hope there are no new
bugs hiding in there, so pl4 should be as stable as pl3 - with the added
advantage of not having the truncate bug. And I haven't gotten any bad
reactions to pl3 yet. On the other hand, I guess most people haven't
had time to upgrade even that far...
Even the pl3 patches, while big, were pretty simple: mostly cleanups and
some relatively straightforward swapping changes. While bugs are always
possible, the pl3/4 changes aren't of the type that keeps me awake
nights wondering if they will work, and are likely to work without major
problems (famous last words...)
Linus
(*) No, I'm not serious. Lack of smilies doesn't /always/ mean I'm dead
serious. Although some problems (especially HD-driver-related) have in
fact been corrected with the help of beta-testers that were ready to
test out several new versions/day. Unsung heroes, and all that...
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: GP faults and other trivia. . .
Message-ID: <1992Sep9.094232.17759@klaava.Helsinki.FI>
Date: 9 Sep 92 09:42:32 GMT
References: <1992Sep8.104048.1@ualr.edu>
Organization: University of Helsinki
Lines: 87
In article <1992Sep8.104048.1@ualr.edu> nmspillers@ualr.edu writes:
>
>Anyhoo, the crux of my question is this--I'm working with Linux 0.96c
>(no patches yet, I want to solve this problem first) and trying to compile
>the kernel. I usually get a general protection fault somewhere in the kernel
>compile, this leads to a 4-11 meg (no lie!) core and the compile degenerates
>into signal 11 and 6 compiler errors. [ deleted ]
There has been some talk about these kinds of things lately, so I might
as well answer this..
If you see intermittent system failure (core dumping in gcc etc) that
are not easily repeatable, and don't necessarily happen at the same
location every time, there are a couple of possible reasons:
(a) kernel bugs
(b) weird/buggy hardware
(c) installation problems
(a) is certainly possible, although the fact that the same thing works
on a lot of other machines/setups does make me wonder about some
reports. (c) on the other hand usually results in easily repeatable
problems: they occur at the same point each time.
The above (mostly deleted) description does sound like a memory problem:
I should probably enable the NMI just to get a warning about it, but I
think current versions of linux disable it at bootup (I think I disable
it as soon as possible as the system cannot handle it during setup, and
after the system is up and running and a NMI could be handled, I never
re-enable them. I haven't looked into in a long time, so I could be
wrong.)
Alternate reasons are disk read errors, although the drivers do check
error conditions, and you should see kernel messages if they occur. And
if you are wondering "why only gcc?", the reason is probably that gcc is
the one program that usually eats up most of your memory, and actively
shuffles things around. So if you have a bad memory chip or the linux
disk driver has some problems, they usually show up in gcc - that's when
all the buffers are in use, and most of your memory is being excercised
a lot.
Note that memory problems are more likely to show up under linux-0.97
and newer: not because they are more fragile, but simply because they
use memory much more dynamically, and are more likely to take full
advantage of the memory you have got.
So the first things to check when seeing problems like the above is if
it's hardware-related: one good way to do this is usually to slow down
the machine to 8MHz or whetever, and see if the errors go away. If they
do, it's probably not a software bug (although races etc can be
timing-dependent: not very frequent). Other things you can do is try
out some system testing software: but note that linux usually is a
better system tester than most of these especially if they run onder
16-bit DOS and don't check 32-bit accesses to high memory etc.
----- change of subject
Reading the above, your reaction might be "he's obviously trying to
blame the hardware to get out of a tight spot". True. But it's also a
case of standard bug-reporting of a operating system: with most other
programs you can usually safely blame the program. While any bug report
is preferable to none, there are things you can do to help me find it
all. So I might as well use this post to mention some of them, true of
most bug-reports:
- mention all the necessary information. Too much data can be
confusing (and boring), and too little can lead to other problems, so
this isn't easy. Use your own judgement, but THINK about it a bit
before.
- try to make it repeatable, and find the minimal example. This is
also almost always difficult or impossible, as the obvious bugs are
certainly fixed, but it helps /a lot/ if you can simplify the bug-report
a bit.
- if you cannot make it repeatable or simple, assume it's a hardware
problem, and start from that. Try different setups. If possible,
different machines, but if not, try to change your setup as much as
possible, and see if anything changes.
- If the problem changes or disappears due to hardware changes, it
might still be a software bug, so you might still want to send it in as
such. But add your test-results to the report. And if the problem
seems to be hardware-independent, mentioning the fact that you tested it
it in your report is likely to get your report a higher priority.
Linus
==================
==================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: problems making a swap partition useable
Keywords: 0.97.1
Message-ID: <1992Sep9.095543.19608@klaava.Helsinki.FI>
Date: 9 Sep 92 09:55:43 GMT
References: <1992Sep8.162500.16716@tamsun.tamu.edu>
Organization: University of Helsinki
Lines: 34
In article <1992Sep8.162500.16716@tamsun.tamu.edu> greg@carnivore.tamu.edu (Greg Economides) writes:
>
>When I do: mkswap -c /dev/hda5 10583, I get this:
>
> mkswap: will not try to make swapdevice on /dev/hda5
>
>I am wondering if mkswap is complaining because the partition does not
>end at an even boundary (or whatever it is that the '+' indicates, I don't
>remember the exact wording in the fdisk intro file).
Hmm. This sounds like the message I put into the original mkfs sources
that checked that mkfs didn't write over the full disk devices (/dev/hda
and /dev/hdb). And as mkswap evolved from that, I assume the test also
did.
The reason you see it on /dev/hda5 is that I wrote mkfs (and the
original mkswap) back in prehistoric times when linux still used the
minix disk-numbering scheme: under minix, /dev/hdb0 (linux's /dev/hdb)
has the same major/minor as linux's /dev/hda5. I guess the test has
never gotten updated, as you see the problems so seldom (most people
don't have or don't use a /dev/hda5).
Actually there is a (ugly) workaround for this, assuming you have an
error-free disk. Just do
# mkswap tmp 10583
# cp tmp /dev/hda5
This won't try to find bad blocks, though, so it's not always a
solution. The real solution is to find the mkswap/mkfs sources, look
the the error message, and either remove the check, or update it to use
the new minor numbers (3,0 and 3,64 instead of 3,0 and 3,5).
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Unable to use floppies under Linux
Message-ID: <1992Sep10.193917.5396@klaava.Helsinki.FI>
Date: 10 Sep 92 19:39:17 GMT
References: <1992Sep10.182648.12564@eua.ericsson.se>
Organization: University of Helsinki
Lines: 35
In article <1992Sep10.182648.12564@eua.ericsson.se> tmpcms@eua.ericsson.se (Carl-Michael Skoog) writes:
>I've installed Linux about 20-30 times, and every single time the filesystem
>ends up corrupted when I use some floppy-related command like tar(with /dev/fd0
>as file, pax and GNU tar alike), dd, fdformat...
[ *BAD* problems deleted ]
This certainly looks like the linux floppy driver has /major/ problems
with your machine - just as a guess I'd assume it's some weird DMA
incompatibility as the floppy driver is the only thing in the standard
kernel which uses DMA.
It would seem that the DMA accesses go all over your memory, resulting
in weird and incorrect behaviour - writing over the wrong buffers,
kernel data structures etc.
>Could it be my hardware that is stabbing my back? 386BSD and MINIX works
>fine though.
>I will be infinitely grateful if someone can help me with this.
As minix and 386bsd works, it would certainly seem to be a bug in the
floppy driver. A very weird one, though - this is the first such report
I've ever seen.
If you are at all familiar with the PC's DMA setup, I'd suggest you take
a look into floppy.c: setup_DMA(), which is the obvious first suspect.
If anybody can come up with suggestions on what could be wrong, I'd
certainly be interested - but as I cannot see the problem, I'm somewhat
at a disadvantage to find it.
On possibility is simply that it's a timing problem: even re-writing the
floppy driver to use the slower outb_p commands instead of the current
immoutb_p() might help.
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: 0.97 patchlevel 5 available
Message-ID: <1992Sep12.182131.2168@klaava.Helsinki.FI>
Date: 12 Sep 92 18:21:31 GMT
Organization: University of Helsinki
Lines: 35
The subject says it all: the newest patches have been uploaded to
nic.funet.fi: pub/OS/Linux/testing/Linus. Patchlevel 5 is available both
as complete source (linux-0.97.5.tar.Z) or as a biggish patch against
patchlevel 4 (linux-0.97.patch5.Z).
Patch 5 fixes the extended filesystem problems (thanks to Remy Card), as
well as including many smaller fixes (some more fs cleanups, the CDROM
patches and several other minor changes). Pl5 finally removes even the
last few header-files that were incompatible with the normal headers, so
the "-nostdinc -I$(KERNELHDRS)" stuff is gone.
Patch 5 should also fix the problems with iopl() that resulted in the
X8514-server having problems with 0.97.pl2 and above.
In case people are wondering, my schedule for 1.0 looks something like
this:
- 0.98 out in about a week: this is essentially 0.97.5 + the tcp/ip
directory, as well as any fixes that may come up. I'll try to get
the loadable driver interface into it too.
- 0.99 out after 0.98 has been shaken down: a month or so.
- 1.0 will be the same as 0.99: the only changes will be eventual
trivial bug-fixes in case 0.99 has some problems. This is just to
try to get over the "X.0" bug syndrome.
There are a few on-going projects: depending on circumstances these will
be implemented sooner or later, so I won't give any promises. These
include: loadable drivers/fs's (alpha-patches already availabla), full
support for different block-sizes (some work still required), and a
extensive rewrite of the mm routines (I'll want to make a vmm interface
similar to the vfs interface for the filesystem routines).
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.97 patchlevel 5 available
Message-ID: <1992Sep12.224241.5864@klaava.Helsinki.FI>
Date: 12 Sep 92 22:42:41 GMT
References: <1992Sep12.182131.2168@klaava.Helsinki.FI> <15255@borg.cs.unc.edu>
Organization: University of Helsinki
Lines: 42
In article <15255@borg.cs.unc.edu> martin@franck.cs.unc.edu (Kevin Martin) writes:
>In article <1992Sep12.182131.2168@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>
>>Patch 5 should also fix the problems with iopl() that resulted in the
>>X8514-server having problems with 0.97.pl2 and above.
>
>I've just tested the 8514/A X server with 0.97.pl5 and it works
>beautifully. The problems with the X server appearing to hang when
>quitting from TWM with the 0.97.pl2 and more recent kernels are
>fixed. Thanks Linux!
Actually, thank Kevin Martin: he was able to give me a good bug-report
that made it pretty easy to track it all down (he even had a minimal
program which showed the incorrect behaviour).
Other changes that pl5 has include:
- slightly edited <asm/io.h>: easily editable IO delay instructions.
The default delay-instruction is now a 'inb' from port 0x80: this
should be a bit safer than the outb. But you can easily change it to
the "standard" two short jumps or whatever.
- malloc() is cleaned up, and 'malloc_grab_pages()' is gone (Biro)
- I cleaned up the internal inode structure a bit: i_data[] is no
longer part of the base inode, but is instead part of the union of
fs-dependent info. Pipes also have their own cleaner interface.
- the msmouse patches are in: currently there is no valid test that a
msmouse actually exists, so linux always says "mouse detected and
installed", but that is nothing to worry about.
- the msdos-fs one-line performance patch is in.
The most important fix for ext-fs users should be the fact that pl5
should fix the ext-fs bugs: the ext-fs patches are essentially the same
that pl3+4 did to the minix-fs. So now the new 'strip' should be safe
on all filesystem types.
Note that the upcoming release of gcc (and thus the upcoming X11 2.0)
will require at least 0.97.pl4 in order to be safely used: I'll probably
make a bootimage of 0.97.5 available for those that don't want to (or
are unable to) recompile the kernel. I'll just wait a day or two to see
if there are some unexpected problems with pl5.
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.97 patchlevel 5 available
Message-ID: <1992Sep13.085901.16695@klaava.Helsinki.FI>
Date: 13 Sep 92 08:59:01 GMT
References: <1992Sep12.182131.2168@klaava.Helsinki.FI> <1992Sep12.214957.620@cambria.columbus.oh.us>
Organization: University of Helsinki
Lines: 52
In article <1992Sep12.214957.620@cambria.columbus.oh.us> bjones@cambria.columbus.oh.us (Bill Jones) writes:
>
>Well I rushed out and got 0.97.5, compiled it and installed it. All of a
>sudden I began to get HD timeout errors (something I haven't seen since
>0.12). Switched back to 0.97.4 and they all went away!?
Argghh. It's probably the outb_p() changes - that is the only thing in
the HD driver that changed. Look into linux/kernel/blk_drv/hd.c - if
you get pl5 by getting the full source, it doesn't define REALLY_SLOW_IO
any more, as I hoped it would be unnecessary. It looks like
#undef REALLY_SLOW_IO
#include <asm/system.h>
#include <asm/io.h>
#include <asm/segment.h>
and you should probably change the "undef" to "define". I'll change it
back for the next version - it seems the REALLY_SLOW_IO define is still
needed on some machines.
If the above doesn't help (it should), you might also take a look at the
actual delay instruction used to slow down IO. This can be found in
linux/include/asm/io.h, and looks something like this:
#ifdef SLOW_IO_BY_JUMPING
#define __SLOW_DOWN_IO __asm__ __volatile__("jmp 1f\n1:\tjmp 1f\n1:")
#else
#define __SLOW_DOWN_IO __asm__ __volatile__("inb $0x80,%%al":::"ax")
#endif
#ifdef REALLY_SLOW_IO
#define SLOW_DOWN_IO { __SLOW_DOWN_IO; __SLOW_DOWN_IO; __SLOW_DOWN_IO; __SLOW_DOWN_IO; }
#else
#define SLOW_DOWN_IO __SLOW_DOWN_IO
#endif
You might change the default slow-down instruction from
__asm__ __volatile__("inb $0x80,%%al":::"ax")
to
__asm__ __volatile__("outb %al,$0x80")
Whatever you do, I'd be very interested to hear what you did, and if it
worked, so that I can get it fixed for the next version.
Also, there seems to be some problem with the extended fs patches:
either Remy's patches or the changes I made to the inode setup. So pl5
still seems to have some irritating bugs. I'll try to find it.
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.97 patchlevel 5 available
Message-ID: <1992Sep13.103027.17973@klaava.Helsinki.FI>
Date: 13 Sep 92 10:30:27 GMT
References: <1992Sep12.182131.2168@klaava.Helsinki.FI> <1992Sep12.214957.620@cambria.columbus.oh.us> <1992Sep13.085901.16695@klaava.Helsinki.FI>
Organization: University of Helsinki
Lines: 14
In article <1992Sep13.085901.16695@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>
>Also, there seems to be some problem with the extended fs patches:
>either Remy's patches or the changes I made to the inode setup. So pl5
>still seems to have some irritating bugs. I'll try to find it.
Well, I also found out that at least named pipes got broken by my inode
reorganizations. Hope nobody is using them - the fix is simple (it's
actually just a lack of proper wait-queue initializations), but I won't
make a patch available until I've found most of these kinds of silly
problems. But if you know you are using named pipes, don't upgrade to
pl5 yet.
Linus
==================
==================
From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: gcc 2.2.2 math lib bug???
Keywords: weirdness
Message-ID: <1992Sep13.175040.24459@klaava.Helsinki.FI>
Date: 13 Sep 92 17:50:40 GMT
References: <1992Sep13.161713.8191@monu6.cc.monash.edu.au>
Organization: University of Helsinki
Lines: 17
In article <1992Sep13.161713.8191@monu6.cc.monash.edu.au> int177c@aurora.cc.monash.edu.au (Jae Won) writes:
>
> I found a weidness in gcc2.2.2d. It may be my silly code but I tested
>the code with gcc compiler at uni(gcc...not sure of the version) and it worked
>fine...well, like what I expected. The code is a edited fragment of a code
>I am writing to do a monte carlo stuff. I use exp() function.
It's more likely to be a problem with the 387-emulator: the emulator
does *not* handle under/over-flows gracefully in its current form. The
fix is either to get a real 387, check for underflows by hand, or fix
the emulator. Fixing the emulator is obviously the optimal solution,
but it takes some doing, and nobody seems interested (most people,
including me, seem to have a 387). The fact that the emulator works
"well enough" for most things makes it a pretty boring project, so
nobody has done anything about it.
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: patchlevel 6
Message-ID: <1992Sep20.171956.26108@klaava.Helsinki.FI>
Date: 20 Sep 92 17:19:56 GMT
Organization: University of Helsinki
Lines: 27
You all know what the subject line means by now: in case you want to
track my kernel versions, the weekly patch is available at nic.funet.fi,
pub/OS/Linux/testing/Linus.
This patch does not contain any major bug-fixes: it corrects named pipes
that broke with pl5, and has some minor changes in the IO-instructions
and the hd-driver, but those shouldn't matter for most of you.
It does contain all the scsi-patches that I've gotten so far, so if the
bootup sequence died on you in the scsi code, pl6 should correct this.
The major part of the patch is tytso's serial line changes, making the
tty structures dynamic. No more NR_PTY's - the number of pty's is now
bounded only by the minor number setup (max 64 pty's) or the amount of
memory available (opening a pty requires a page of memory for tty
queues). Similarly for serial lines.
The above just means that while pl6 can be useful, the changes to pl5
aren't big enough to worry about. Most people don't use named pipes, it
seems, and the other changes are either cosmetic or hardware-dependent.
I still hope people upgrade, if only so that I can get new bug-reports.
I had hoped to release 0.98 this weekend, but studies and the scsi/hd
problems put an end to that. 0.98 should be out next weekend or so.
Expect the tcp/ip subdirectory and possibly some mm changes.
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: patchlevel 6
Message-ID: <1992Sep20.214558.1338@klaava.Helsinki.FI>
Date: 20 Sep 92 21:45:58 GMT
References: <1992Sep20.171956.26108@klaava.Helsinki.FI>
Organization: University of Helsinki
Lines: 12
In article <1992Sep20.171956.26108@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Torvalds) writes:
>You all know what the subject line means by now: in case you want to
>track my kernel versions, the weekly patch is available at nic.funet.fi,
>pub/OS/Linux/testing/Linus.
Arggh. While the full source was ok, the patch was generated with
"+ignore-all-spaces" in the hope that it would be smaller that way. And
yes, the patch is smaller, but it doesn't actually work :-( The full
source to pl6 is ok, but if you got only the patch, you'll get errors
when applying it. I'll put a corrected patch at nic at once.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.unix.sysv386,comp.windows.x,comp.os.linux,comp.unix.bsd,comp.os.mach,comp.sys.ibm.pc.misc,comp.sys.ibm.pc.hardware
Subject: Re: Free software and the future of support for Diamond products
Keywords: Diamond, free-software
Message-ID: <1992Sep21.164816.9162@klaava.Helsinki.FI>
Date: 21 Sep 92 16:48:16 GMT
References: <1992Sep20.000851.2641@cbnewsj.cb.att.com> <1992Sep21.150821.9472@crd.ge.com> <1992Sep21.154451.10085@cbnewsj.cb.att.com>
Organization: University of Helsinki
Lines: 33
In article <1992Sep21.154451.10085@cbnewsj.cb.att.com> dwex@cbnewsj.cb.att.com (david.e.wexelblat) writes:
>In article <1992Sep21.150821.9472@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>>
>> Youu've missed something. The kernel supports vm86 operation, and it
>> is possible to drop into real mode, allow access to the i/o ports
>> needed, and run the BIOS in real mode, then exit back to protected mode.
>> I am not suggesting this, I'm just saying it can be done.
>
>Well. Learn something new every day. Does anyone have a code sample that
>shows how this may be done?
Hmm. The linux alpha DOS-emulator might be able to do it with some
minor tweaking: you'd have to get the initial 'int 0x10' address from
somewhere (as it's normally over-written by the kernel), and the process
should do a mmap("/dev/mem") the put the bios/screen memory into the
normal address space. Additionally, you can use the iopl() system call
to give the process IO priviledges before switching to vm86 mode - that
way you don't even have to emulate any IO instructions. Some additional
setup to initialize the normal BIOS data areas, and off you go. The
only thing that doesn't work with the current linux setup is to get the
original offset to the 'int 0x10' call: a minor kernel diff to look it
up at bootup would be possible.
I don't know how other systems would do it, but it should certainly be
possible - but I do not think it's a good idea. It's ugly, and it's not
guaranteed to be safe: the BIOS call might do something nasty while it
has IO priviledges if it assumes a normal DOS setup and the vm86 setup
is incomplete. Besides, that way you can only set modes that the BIOS
knows about - the X386 (XFree86) driver has already proven that
programming the chipset directly can lead to much better results (ie
nonstandard resolutions etc).
Linus
==============================
==============================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.97p6: no PGUP; NUM_LOCK?
Message-ID: <1992Sep23.072224.24351@klaava.Helsinki.FI>
Date: 23 Sep 92 07:22:24 GMT
References: <1992Sep23.014210.19842@unislc.uucp>
Organization: University of Helsinki
Lines: 28
In article <1992Sep23.014210.19842@unislc.uucp> erc@unislc.uucp (Ed Carp) writes:
>Two questions:
>
>1. Somewhere between p5 and p6, I lost Page Up and Page Down key
> functionality for vi. Any bright ideas?
In order to be more vt100 compatible, those keys (and the function keys)
now send slightly different codes. I haven't seen any problem: at least
uemacs worked fine both before and after. It's just an ongoing project
of mine to foil all vi-users :-)
>2. Isn't there a patch to turn NUM LOCK off when linux fires up?
It's already in the standard kernel (as of pl6) - I think the thing to
do is to add
-DKBD_DEFLOCK=0
to the KEYBOARD define in the main Makefile (the same line that contains
the "-DKBD_FINNISH" or whatever). You can also define any other standard
lock defaults by changing the above to
-DKBD_DEFLOCK=NUMLOCK+CAPSLOCK
or similar. I haven't tested it - the define might be wrong, but check
the keyboard.c file to see how it works.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.97 p6's README etc.
Message-ID: <1992Sep23.124326.10022@klaava.Helsinki.FI>
Date: 23 Sep 92 12:43:26 GMT
References: <1992Sep23.051532.22588@wixer.cactus.org>
Organization: University of Helsinki
Lines: 34
In article <1992Sep23.051532.22588@wixer.cactus.org> rhodesia@wixer.cactus.org (Felix S. Gallo) writes:
>
> The README under 0.97 p6 now seems to have a few minor
>faults. NR_PTYS, which it suggests is in include/linux/tty.h,
>is no more. It seems to have been replaced by NR_CONSOLES, but
>I'm hazy on this point right now.
NR_PTY's does indeed not exist any longer - pty's are now dynamic, and
you can have as many as the naming scheme (you fight it out) and the
minor numbering (max 64) allows (assuming you have enough memory).
NR_CONSOLES is a distinct entity: this defines how many virtual consoles
you have (normally 8, although I think the standard init setup starts a
login process only on the first 4). It's still hardcoded, and I don't
think there is any pressing need to make the VC's dynamic.
> But the really heinous thing, the absolutely worst
>thing that could happen -- and the reason I'm dumping linux
>immediately and buying windows 3.1 -- is that, at the very end
>of the README, ever since 0.96c (as far as I can tell), the
>signature is "Lars Wirzeniu". Please fix this glaring kernel
>error *IMMEDIATELY!*
This isn't a bug - it's just that I'm too lazy to write anything like
the README, so Lasu wrote it, and I just put my own comments in there.
But I can understand that windows 3.1 would seem like a much better
alternative after reading the README. The "bug" is almost as heinous as
the wrong patchlevel numbers that plagued the 0.96XX releases...
(and if the "bug" is the missing "s" from "Wirzeniu" (yes, I like
"quotes" (and parentheses)), then that is probably just due to 8-char
user-name truncation that has taken over from unix)
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Finally: 0.98
Message-ID: <1992Sep29.211121.15619@klaava.Helsinki.FI>
Date: 29 Sep 92 21:11:21 GMT
Organization: University of Helsinki
Lines: 35
Sorry for being late - I can't even show any great new features in 0.98,
but at least it's out now, and available at the normal place (ie at
nic.funet.fi, pub/OS/Linux/testing/Linus). So far there is only a
full-source version available, although I'll probably make it available
as a patch too tomorrow or so (but the patch won't contain the tcp/ip
stuff).
0.98 is essentially the same as 0.97.pl6 - the changes are mostly:
- tcp/ip (0.8.1) is in. It's not compiled into the standard bootimage,
and you'd better be on the tcpip mailing-list to use it, but it's
there. I've been unable to test it further than just watch it
compile...
- extfs patch to correct the problem with big directories with holes.
- mouse patches (ie improved detection-routines)
- minor scsi patches (ultrastor driver change)
- swiss keyboard
- some serial driver patches
- the 32mb patches are in, so if you aren't using a DMA-SCSI driver,
and have more than 16MB physical memory, you can get it recognized.
- edited hd.c
- corrected core-dumping routines
I didn't get my mm patches working yet, so they'll have to wait. The
above are almost 100% by others - I have edited some of the patches, but
there is nothing major new by me. Most of it is minor bug-fixes, and
the only thing that might be a bit of a problem are the hd.c changes:
but I hope they'll solve more problems than they cause. Knock wood.
At nic.funet.fi you can currently find (a) the full sources (b) a
bootimage (US keyboard, floppy root, no tcp/ip) and (c) the protocols.h
file needed for compiling the tcp/ip directory (which should go into
/usr/include/netinet/). I hope people try it out, and that there are no
new problems with this release.
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Where's Linus
Message-ID: <1992Sep30.091651.29547@klaava.Helsinki.FI>
Date: 30 Sep 92 09:16:51 GMT
References: <1992Sep29.213232.7178@mcshh.Hanse.DE>
Organization: University of Helsinki
Lines: 23
In article <1992Sep29.213232.7178@mcshh.Hanse.DE> umisef@mcshh.Hanse.DE (Bernd Meyer) writes:
>The subjext says it all - according to my newsreader Linus showed up
>last on the 23rd of September - a week ago.
>Is he off for holidays?
>Did Bill Gates hijack(?) him?
>
>What has happened....
Oh, I'm here all right, and I've read all of c.o.l, but I haven't had
much time/energy to do anything constructive. Also, I'm happy to say
that most problems seem to be solved by others, and the rest of the
discussion has been the 386bsd-linux flamewar which I didn't bother to
respond to. I've also read all the mail I've gotten, although I've kept
replies to a minimum.
It also seems a lot of the linux-discussion has moved over to strictly
user-level problems (and I couldn't be happier), and/or kernel problems
I can't do much about (msdos fs problems etc). That is likely to change
again now that 0.98 is out (already one report that the hd.c changes
result in apparently harmless "unexpected hd interrupt" messages on one
machine). Oh, well.
Linus
============================
============================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Xega and system lockup
Message-ID: <1992Oct1.082802.13843@klaava.Helsinki.FI>
Date: 1 Oct 92 08:28:02 GMT
References: <MMH.92Sep30133155@mercury.analog.com> <L5sXRB2w165w@dogear.spk.wa.us>
Organization: University of Helsinki
Lines: 19
In article <L5sXRB2w165w@dogear.spk.wa.us> bobk@dogear.spk.wa.us (Bob Kirkpatrick) writes:
>
>I have a Logitech BusMouse...
>
>I've discovered that using ...tst/mouse/mouse produces the error
>message "Stack Overflow on IRQ5"
You are definitely using an older version of linux - try upgrading to
either 0.97.pl6 or 0.98 (which will probably need the mouse-patch that
was posted a day or two ago). The Stack overflow message is part of an
older kernel (0.96c? something like that), and was fixed in 0.97.
Note that 0.96c (which at least the current version of SLS seems to be
based on) was a pretty stable release - but it is a bit old... Keeping
up with the absolutely newest versions of linux may not be very safe,
but there are problems with keeping to old kernel versions too. After
all, I don't make new releases *just* to annoy people.
Linus
==============================
==============================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: bootimage 98 boot video problems
Keywords: 98 video bootimage
Message-ID: <1992Oct1.212454.17196@klaava.Helsinki.FI>
Date: 1 Oct 92 21:24:54 GMT
References: <perry.24.717954911@seq.uncwil.edu>
Organization: University of Helsinki
Lines: 20
In article <perry.24.717954911@seq.uncwil.edu> perry@seq.uncwil.edu (Steve Perry) writes:
>Hi,
> I have been using Linux since .12 and have had no problems with my
>monitor until .98. I went and got the bootimage-.98 from tsx, ftp'ed
>it to my PC (in bin mode), uncompressed it, used rawrite to put it
>on a floppy. Now when I boot from the floppy it runs thur the "Loading..."
>line ok but as soon as it starts to print out the boot up stuff, the screen
>loses it.
Argghh ... Nothing wrong with 0.98 (that part hasn't changed for a
while), but I compiled the bootimage with my monitor settings (ie
"SVGA_MODE = -DSVGA_MODE=1" in the main makefile). This probably won't
work on a non-VGA setup, and even with VGA you get the hardcoded startup
mode, which is probably not what you want.
The solution is probably to recompile the kernel with the SVGA_MODE
line uncommented, or to wait until I (or somebody else) can get a new
bootimage out the door.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: BUGS (even more minor)
Message-ID: <1992Oct2.090825.5086@klaava.Helsinki.FI>
Date: 2 Oct 92 09:08:25 GMT
References: <1992Oct1.221854.36218@uservx.plk.af.mil>
Organization: University of Helsinki
Lines: 12
In article <1992Oct1.221854.36218@uservx.plk.af.mil> simonich@uservx.plk.af.mil writes:
>It seems that the setting for NUM LOCK got lost when 0.98 Makefile
>was released. It would be nice to have it back.
It's there: I just rewrote the way the initial NUMLOCK is set. The
default is numlock on, but you can set any default lock-values by
defining the KBD_DEFLOCK define to whatever you want. So if you want no
locks on by default, add a "-DKBD_DEFLOCK=0" to the main makefile line
that defines the keyboard. Look into linux/kernel/chr_drv/keyboard.c for
details.
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: VERY DETAILED history of Linux in its early days
Message-ID: <1992Oct2.090325.4664@klaava.Helsinki.FI>
Date: 2 Oct 92 09:03:25 GMT
References: <1992Oct2.005443.18476@sbcs.sunysb.edu>
Organization: University of Helsinki
Lines: 95
In article <1992Oct2.005443.18476@sbcs.sunysb.edu> synchem@sbcs.sunysb.edu (Synchem proj acct) writes:
>
>1. Does anyone still have a copy of Linux 0.01, or is it 0.11,
> when all Linux does was switching two processes printing AAAA, BBBB...?
> Or some very earliest version of Linux?
The AAABBBB version certainly doesn't exist anywhere - that was long
before I thought it was worth it to make it freely available. While
0.01 wasn't much, at least it *did* work as a simple unix clone.
The oldest version that I was able to find with some fast ftp'ing was
the 0.10 version of linux - and that most definitely did work (that's
about the time when I tried to autodial my harddisk, and lost all my
minix files...). 0.10 had some serious problems (no floppy driver if I
remember correctly, and a bad bug in the buffer code), but it already
ran gcc etc happily. And it's only 130kB in size - the current kernel
is >600kB (but new drivers are a big part of that..)
>2. An as detailed as possible description of things that are gradually
> added to Linux since when it can only print AAAA, BBBB? And the design
> decisions? I guess up detailed descriptions would be needed for only
> up to 0.12. Things after that can most likely be found in textbooks.
I've promised to write down what I remember (which isn't much) some time
ago, but I haven't got around to it yet (writing not being my favourite
pastime).
Design decisions: none. Linux wasn't designed - it grew over a period
of time, and I'm still impressed by how few bad decisions I've made so
far (I've had to rewrite a lot, but nothing *really* broken). There
were a couple of guidelines: keep it simple, and do it the easy way. On
the other hand, I started with a pretty good idea of what I wanted, and
I had the truly basic thing (multitasking) going at the very beginning.
Stages (1991):
- get into protected mode [Feb-Apr]. This isn't easy - especially if
you are learning the assembly language and the quirks of the PC
architecture as you go. This took several months (I made some small
trials in this direction even before I got minix).
Simple screen-IO came up here - mostly because that was the only way
I could announce any kind of success. Poking a few long-words to
screen memory and having a delay was the easiest way to show that the
program had gotten enywhere.
- multitasking. Getting a timer interrupt to work, and to switch
between two tasks. This is where the first simple tty driver came
into play, and when I printed out the AAA BBBB things. No memory
management, no frills, just two different threads that got switched
around by the 386 task-switching primitives.
- basic drivers [May-June]. Mostly getting interrupts to work,
refining the tty driver, getting the serial lines working (hardcoded
to 2400bps until version 0.10 or so, because that was/is all I have).
I used "linux" mostly as a terminal emulator by this time: it was
written 100% in assembly, and did terminal emulation by having two
threads: one read the keyboard and wrote to the serial line, the
other read the serial line and write to the screen.
By this time I had gotten confident enough about the system that I
could start using C - but I think the console driver was in assembler
until version 0.11 or so. I still had no harddisk drivers, no memory
management and no filesystem.
- basic harddisk driver, minix-fs, buffer cache [June-July]. These
were somewhat intertwined: I needed all of them to be able to test
things. The harddisk driver was first, then a simple buffer cache,
then some basic fs routines. But they all got changed as other parts
evolved.
- basic system resources - mm, system calls, and refinement of the old
parts [July - Aug]. This is where I started writing small linux
programs to test out things. Mostly they were still hard-coded into
the kernel - the system was still not up to a real fork/execve. I
got there slowly, and eventually was able to port the minix shell to
linux. Glorious day (but I've forgotten when this was :-).
- basic enhancements - [Aug-91 - Sept-92] getting gcc to work (which
really needs a working buffer cache..), porting basic utils, making
it all available.. Getting X running, etc :-)
Note that the above is a very much simplified history, and the dates are
only "so-so" - they can be off by a month or two. Also, the
developement wasn't as modular as the above would have you believe:
that's just a rough timetable. And even when I first released it, 0.01
never really worked: it was just a source release (September-91?).
>3. What are the considerations of in deciding what goes into kernel
> and user space?
As much as possible goes into user space, as long as it's not too much
of a bother. If something gets much easier or cleaner (387-emulation)
by being in the kernel, then so be it.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Readership report..
Summary: sept-92 readership
Message-ID: <1992Oct2.103435.8586@klaava.Helsinki.FI>
Date: 2 Oct 92 10:34:35 GMT
Organization: University of Helsinki
Lines: 62
In case somebody doesn't follow news.lists, here are selected parts of
the september-92 readership reports. In case you want the full report,
it's available in news.list along with some other general news-related
reports.
Interestingly, comp.os.linux propagation has gone up from just 56% to
71% within the last month. At the same time, the estimated total number
of readers figures have become smaller by a noticeable amount - but not
just for linux. There have probably been some changes to the way the
readership is counted.
For those that think linux is an active group: you are right. We aren't
far behind alt.sex (THE newsgroup when it comes to popularity - although
some other groups do have a bigger audience) in number of articles, and
linux has been in the top 40 in both traffic volume and cost-per-reader
for the last few months.
As to actual popularity: propagation is still pretty low (80% is normal
for a comp group it seems), but being the 335th most popular group isn't
bad for this kind of specialized group.
Linus
--- edited list follows ---
This is the full set of data from the USENET readership report for Sep 92.
Explanations of the figures are in a companion posting.
+-- Estimated total number of people who read the group, worldwide.
| +-- Actual number of readers in sampled population
| | +-- Propagation: how many sites receive this group at all
| | | +-- Recent traffic (messages per month)
| | | | +-- Recent traffic (kilobytes per month)
| | | | | +-- Crossposting percentage
| | | | | | +-- Cost ratio: $US/month/rdr
| | | | | | | +-- Share: % of newsrders
| | | | | | | | who read this group.
V V V V V V V V
1 160000 5317 83% 980 1933.6 22% 0.02 11.5% misc.jobs.offered
2 160000 5142 82% 1568 1909.7 40% 0.02 11.1% misc.forsale
3 150000 4788 89% 10 157.9 100% 0.00 10.3% news.announce.newusers
4 120000 3910 68% 2556 6290.4 45% 0.07 8.4% alt.sex
...
20 68000 2241 86% 1120 2335.9 15% 0.06 4.8% comp.lang.c
...
69 44000 1448 85% 945 1622.4 15% 0.06 3.1% comp.unix.sysv386
...
119 36000 1186 76% 1381 3445.7 2% 0.14 2.6% comp.unix.bsd
...
128 35000 1140 85% 534 902.9 11% 0.04 2.5% comp.unix.ultrix
...
262 25000 830 81% 10 11.1 10% 0.00 1.8% comp.os.misc
...
335 22000 733 71% 2392 4082.2 2% 0.26 1.6% comp.os.linux
...
365 21000 705 83% 139 327.0 5% 0.03 1.5% comp.os.minix
...
606 15000 498 76% 688 988.4 0% 0.10 1.1% comp.os.coherent
...
892 10000 345 79% 4 5.5 25% 0.00 0.7% comp.unix.sysv286
..
1577 1500 48 9% 24 31.7 0% 0.00 0.1% houston.eats
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Once again -- FileSystem corruption
Message-ID: <1992Oct4.074930.23728@klaava.Helsinki.FI>
Date: 4 Oct 92 07:49:30 GMT
References: <t6bp+pk+@aix01.rz.fht-mannheim.de>
Organization: University of Helsinki
Lines: 28
In article <t6bp+pk+@aix01.rz.fht-mannheim.de> mrex@aix01.rz.fht-mannheim.de (Martin Rex) writes:
>
>It still might be a problem with my Maxtor 7213 (PCBA rev 52 -- june '92)
>but to me it looks like linux is maybe not fault-tolerant enough.
Well, it's true that linux has some problems with bad spots on the disk
(as I have never been able to see one...), but in the case of the maxtor
drive (and you do have one of the early bad ones - PCBA < 63) it's just
that the maxtor doesn't seem to *report* the errors, so linux doesn't
even know about any trouble.
The drive seems to work perfectly ok under DOS - but DOS (BIOS) doesn't
even use interrupts in the harddisk driver. Does the maxtor work under
OS/2?
>I don't want to say linux is bad in any way,
>but maybe it's possible to add some switches to offer conservative
>timings for poor/flawed hardware ?
There already is, both in {in,out}b_p() and in the HD_DELAY values. But
with so many different systems (and so few hardware manuals), it's a bit
difficult to please everybody. The default delay of inb_p/outb_p is
four extra IO instructions - that is very conservative (at least my
drive works without any delay at all). The HD_DELAY define isn't used
by default: it's a pretty ugly hack, and I don't like it (but it does
help some people, so...).
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Weird disk corruption (tar off msdos partition)
Message-ID: <1992Oct4.072803.23147@klaava.Helsinki.FI>
Date: 4 Oct 92 07:28:03 GMT
References: <lcrnvkINN1s3@ozona.cs.utexas.edu> <3835@ra.nrl.navy.mil> <lct1i3INN31p@ozona.cs.utexas.edu>
Organization: University of Helsinki
Lines: 31
In article <lct1i3INN31p@ozona.cs.utexas.edu> jefftep@cs.utexas.edu (Jeffrey Grills) writes:
>
> maxtor 7213a hd (never had any timeouts)
>
>I think there is some underlying problem. I've had tons of things weird
>happen that have never had real solutions discovered for. For instance,
>I think but cannot verify the following accusations:
>
> I've compared 2 files multiple times, getting 3 different results from cmp
> I'm one of the people that gets Signal 11 from gcc/cc1 (still on occasion)
> I've had the kernel complain about "swap weirdness" once (something like that)
> I've done the cat|uncompress|tar thing and had tar complain about a bad input
> file, only to try it again, with no changes, and have it work fine
Definitely sounds like the buffer corruption problem with older maxtor
7213A's.
Here is an excerpt from a post by swaliff@afterlife.ncsc.mil (Steve Aliff):
>
> Some of you may have been following my trials and tribulations with
> a Maxtor 7213A under Linux. I spoke with Maxtor tech support today,
> and they agreed that there was a problem with early 7213As and the
> commercial variants of Unix (Xenix, SCO). If you have a 7213A whose
> PCBA number is less than 63, then you may have a problem with it
> under Linux. My present drive's PCBA number is 54. (The PCBA number
> is their revision tracking number of the on-board controller board.)
> The PCBA number is listed on the label on top of the drive.
Upgrading to a newer 7213A helped at least Steve.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: unexpected interrupt?
Message-ID: <1992Oct4.080658.24234@klaava.Helsinki.FI>
Date: 4 Oct 92 08:06:58 GMT
References: <1992Oct4.014156.11412@athena.mit.edu>
Organization: University of Helsinki
Lines: 42
In article <1992Oct4.014156.11412@athena.mit.edu> pmacdona@tadpole.bcsc.gov.bc.ca writes:
>Sorry if I missed it, but is the fix to the "unexpected interrupt"
>problem in .98 just to bump up the HD_DELAY?
No, the fix is this one-line "patch" to linux/kernel/blk_drv/hd.c (at
the end of the read_intr() function):
----- "patch" -----
if (i > 0) {
SET_INTR(&read_intr);
sti();
return;
}
+ (void) inb_p(HD_STATUS);
#if (HD_DELAY > 0)
last_req = read_timer();
#endif
do_hd_request();
return;
}
----- "patch" -----
That is, add the "(void) inb_p(HD_STATUS)" line. Don't try to run the
above through patch - do it by hand, or wait for the first "official"
patch to 0.98 which has this and some other patches (possibly out later
today).
In case somebody wonders what happened to the hd-driver between 0.97.pl6
and 0.98: I removed the status-checking after reading the controller RAM
buffer. Reading the status could (on some hardware with a fast disk)
result in an acknowledge of the *next* interrupt, which linux would then
wait in vain for.
The above patch does read the HD_STATUS register - but it does so only
after we have gotten all the interrupts we expect from the current
read-request. So the above should (and does) fix the drives that need
the inb() while not breaking anything else.
0.98 also has some other changes to hd.c, but those are mostly minor
reorganizations of the read/write interrupt handlers.
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 8 bit console
Keywords: kernel keyboard french patch
Message-ID: <1992Oct5.164318.17472@klaava.Helsinki.FI>
Date: 5 Oct 92 16:43:18 GMT
References: <1992Oct5.025000.18463@sobeco.com> <Oct.5.03.03.37.1992.6708@geneva.rutgers.edu> <1992Oct5.140408.25274@wam.umd.edu>
Organization: University of Helsinki
Lines: 15
In article <1992Oct5.140408.25274@wam.umd.edu> joel@wam.umd.edu (Joel M. Hoffman) writes:
>What I was really asking is if the >kernel< is 8-bit clean.
>E.g., can I use an 8-bit clean version of Emacs (which I have) to make
>filenames with all 8-bits?
There should be no problems with 8-bit characters anywhere in the kernel
- but problems arise especially with current versions of bash as well as
various other programs (even 'ls' needs the "--literal" flag to
correctly print out 8-bit filenames).
So while the kernel should handle them ok, I'd suggest against using
8-bit characters in filenames etc, as you'll have problems with 7-bit
terminals, programs that cannot handle them etc etc.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Patch 1 for 0.98 out...
Message-ID: <1992Oct5.170703.3832@klaava.Helsinki.FI>
Date: 5 Oct 92 17:07:03 GMT
Organization: University of Helsinki
Lines: 15
nic.funet.fi: pub/OS/Linux/testing/Linus contains the first patch to
0.98 (along with a bootimage and the full source for those that don't
like to patch).
Patch1 to 0.98 mainly corrects some driver problems: it contains the
added "inb_p(HD_STATUS)" for hd.c, as well as a changed mouse driver
setup (hope it works - I couldn't test it..). There are also some SCSI
driver patches: the seagate driver uses irqaction() to get irq's, and
the aha1542 driver has the speedup patches.
The bootimage should be compiled without the auto-SVGA mode, so people
who had problems with linux automatically using a SVGA mode should be ok
in this release.
Linus
===========================
===========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Kernel Panic
Message-ID: <1992Oct6.092442.29291@klaava.Helsinki.FI>
Date: 6 Oct 92 09:24:42 GMT
References: <1992Oct6.055750.8976@athena.mit.edu>
Organization: University of Helsinki
Lines: 25
In article <1992Oct6.055750.8976@athena.mit.edu> chchen@stat.fsu.edu writes:
>After I installed 4 256k SIMMs to make my system 5 mb RAM, I've been
>having kernel panic problems, especially after I stopped using the
>modem. The message was:
>
>ldt[0]: 00000000 00000000
>ldt[1]: 0000ffff 00cbfb00
>ldt[2]: 0000ffff 00cbf300
>Kernel Panic: We don't support seperate I&D
>
>Any clue? I don't know what it means.
This should definitely never happen - linux doesn't support separate
I&D, and never creates a process that tries to use it. I put in the
sanity-check just because I'm paranoid, and it seems to have paid off
(and besides, everyone *is* out to get me).
So the only reason I can come up with for this particular error message
is that your RAM chips are too slow or have some other problems (bad
connections, whatever) resulting in memory corruption. Alternatively,
the kernel might be overwriting some of it's own data, but as the only
change seems to have been your RAM-upgrade, faulty RAM does seem to be
the likely solution. Try re-seating the SIMMS, or just remove them.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Compiling TIN doesn't work
Message-ID: <1992Oct7.090155.16388@klaava.Helsinki.FI>
Date: 7 Oct 92 09:01:55 GMT
References: <Z0s7RB2w164w@field.ichaos.nullnet.fi>
Organization: University of Helsinki
Lines: 34
In article <Z0s7RB2w164w@field.ichaos.nullnet.fi> kkk@field.ichaos.nullnet.fi (Kristo Kaarlo Matias) writes:
>My porting saga continues... Now it's TIN 1.1 PL1. "make sysv" produces
>this:
>
>signal.c: In function 'set_signal_handlers':
>signal.c:45: 'SIGBUS' undeclared (first use this function)
>[...]
>signal.c: In function 'signal_handler':
>signal.c:102: 'SIGBUS' undeclared (first use this function)
>
>What the heck is this 'SIGBUS'? I didn't found it at /usr/include/*.
Argghh. This comes up every once in a while (about twice a day to be
exact), and the answer is that tin is not posix, and uses an obsolete
signal that linux doesn't use, but which exists under both sysV and bsd,
so most sources don't seem to bother checking about it.
The thing to do is to search for SIGBUS in the sources, and put a
#ifdef SIGBUS
...
#endif
around the offending code. It *could* be solved by adding a dummy
signal value to /usr/include/signal.h ("#define SIGBUS 31" or similar),
but the problem isn't really in the linux code but in the sources that
assume SIGBUS is defined.
>I have Linux 0.98 and GCC 2.2.2d. I compiled TIN with -DPOSIX_JOB_CONTROL,
>is this ok?
POSIX_JOB_CONTROL is ok.
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Once again -- FileSystem corruption
Message-ID: <1992Oct8.075539.22908@klaava.Helsinki.FI>
Date: 8 Oct 92 07:55:39 GMT
References: <1992Oct4.074930.23728@klaava.Helsinki.FI> <705559005snx@grendel.demon.co.uk>
Organization: University of Helsinki
Lines: 41
In article <705559005snx@grendel.demon.co.uk> jes@grendel.demon.co.uk (Jim Segrave) writes:
>In article <1992Oct4.074930.23728@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Torvalds) writes:
>>
>> The drive seems to work perfectly ok under DOS - but DOS (BIOS) doesn't
>> even use interrupts in the harddisk driver. Does the maxtor work under
>> OS/2?
>>
>As far as I know, every BIOS hard disc driver does use interrupts.
Hmm. I have only the IBM AT technical manual to check from (which does
include the BIOS disassembly), and at least that BIOS (original IBM AT)
does not use interrupts for the harddisk, but busy waiting (actually,
the interrupt *is* used to set the flag that the BIOS is waiting on, but
that's it).
Linux does all the IO processing in the actual interrupt routine, which
probably makes it a bit more timing-critical than some other solutions.
> A
>common problem with older BIOS's is that some IDE drives will raise the
>interrupt on a read before the drive is actually ready to transfer data.
>Older BIOS's often simply begin reading the data as soon as the
>interrupt is received and in some cases - I found this with Quantam
>drives, the data is replaced with garbage.
Yes, linux had the same problem in earlier drivers (pre-0.96 I think),
and there were some reports about trouble with Quantum drives.
> The code needs to wait for
>the interrupt to occur, then wait for the data ready flag in the status
>register (or better still the alternate status register) before
>performing data transfers.
Linux already does this (but I don't see any reason for using the
alternate status register - the function is exactly the same aside from
accnowledging the interrupt). The problem seems to be something else
with the maxtor drives - my guess is that the status register isn't
always up-to-date or similar. I'm still looking into it and trying to
find safe ways to make it a bit less timing-critical.
Linus
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Chicken and egg: How was the first linux gcc binary created??
Keywords: gcc linux egg chicken soup
Message-ID: <1992Oct12.100843.26287@klaava.Helsinki.FI>
Date: 12 Oct 92 10:08:43 GMT
References: <1992Oct10.124926.12423@engr.uark.edu>
Organization: University of Helsinki
Lines: 59
In article <1992Oct10.124926.12423@engr.uark.edu> tep@engr.uark.edu writes:
>
> As I was standing in the shower this morning I was thinking (I do
>my best thinking in the shower) "How did Linus generate that first
>gcc binary?" This was prompted by a newbie question about compilers
>where he said something like "I can't compile a compiler until I have
>a compiler to compile it."
>
> I guess Linus is the only one who can answer this but I figured it
>would also be of general interest. So Linus, how'd ya do it???
As has already been noted, it's fairly easy to cross-compile gcc from
one system into another, and that is what I did.
The original gcc I used was the minix gcc (1.37.1) by Alan W Black (and
somebody.. forgotten who?), which did some very ugly things in order to
handle floating point. I used that to compile gcc-1.40 for minix, with
patches by Bruce Evans to clean up the floating point handling and some
of my own patches (I fooled around with gcc when learning about it, and
added a "-mstring-insns" switch which allowed gcc-1.40 to use the 386
string instructions for structure copying etc).
The minix-386 (thanks again, Bruce - without the 386 patches for minix I
would never have gotten anywhere) I was running by that time was able to
execute normal gcc binaries directly (the only major diff I did to minix
- and awb later made a better version of it), which is also the standard
linux binary format. So the same gcc binary running under minix could
make both minix and linux binaries: the only thing that differed was the
startup routine (crt0.o) and the standard library. My first binaries
used modified minix library routines, and the first shell I used under
linux (pre-0.01) was the minix bourne shell recompiled with those
library routines.
The binaries I later released used a library that was heavily based on
Earl Chew's (free) estdio package (thanks), with some minor routines by
me and some from various other sources (I think the minix termcap
routines were free etc). Back then (0.01-0.11), the biggest problem
with gcc were the libraries - estdio worked (even though it had it's
quirks) but many other routines were either incomplete or missing.
Porting many programs meant I had to write new library routines or find
them from some other source (like the early and very buggy glibc.a).
Also, I wasn't able to compile binaries under linux until version 0.10
or so - all the major first binaries (notably bash) were crosscompiled
from minix. The reason was the bad buffer-cache bugs in early linux
versions which made running gcc (which easily fills the buffer-cache)
impossible. 0.03 was able to run a gcc binary, but recompiling gcc
itself under linux led to weird crashes due to the buffer cache
corruption.
By 0.11-0.12, hlu had showed interest in maintaining gcc-2.x (I checked
out early snapshots of the alpha sources), which meant I had to
implement the math-emulation in the kernel, so that gcc wouldn't need
the patches for integer floating-point. By that time glibc.a also
started to be partly useable, so the linux libraries started using that
more and more (with some bad bugs as a result in the early versions).
The rest is history.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.unix.bsd,comp.os.linux
Subject: Re: Binary compatibility question... [Summary]
Message-ID: <1992Oct15.092205.28084@klaava.Helsinki.FI>
Date: 15 Oct 92 09:22:05 GMT
References: <1992Oct13.223537.11949@ucsu.Colorado.EDU> <1992Oct14.014146.20610@tfs.com> <1992Oct14.193014.537@ucsu.Colorado.EDU>
Organization: University of Helsinki
Lines: 25
In article <1992Oct14.193014.537@ucsu.Colorado.EDU> ngoh@rintintin.Colorado.EDU (NGO HIEN D) writes:
>
>From: Cameron Spitzer 764-6339 <camerons@nad.3com.com>
>
>There *is* an "Application Binary Interface" for System V on the [34]86.
>I was real disappointed to find out Linux doesn't use it. Don't know why he
>doesn't either.
The simple reason linux isn't even close the the intel ABI is that I
simply hadn't got a clue about how it looked - intel never contacted me
about it :-) and I certainly didn't want to go to any unnecessary
trouble over it.
As it turns out, the linux-ss project might be helped by linux following
the intel ABI or at least being a bit closer (ie lcall 7,$0 for system
calls), so I might put in some hooks for it - I'll take a look at the
xenix emulator when I get some time.
Making linux run most normal i386 ABI binaries would probably be pretty
simple: you'd just need a simple wrapper around the system calls
mechanism. To get more complete support, the signal handler stack frame
would have to be changed etc, but very few programs care about that
anyway.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Kernel panic!?
Message-ID: <1992Oct15.093427.29150@klaava.Helsinki.FI>
Date: 15 Oct 92 09:34:27 GMT
References: <1biei2INN2mc@crcnis1.unl.edu>
Organization: University of Helsinki
Lines: 31
In article <1biei2INN2mc@crcnis1.unl.edu> mchapin@cse.unl.edu (Mark Chapin) writes:
>In attempting to install the SLS package, I partioned my hard drive several
>times using fdisk from Linux, DOS and even OS/2. After every attempt I use
>mkfs -c /dev/hda2 57344 (with or without the -c) . No matter what I do I
>get Kernel Panic: Trying to write bad sector.
>Wassup? I have an ESDI 660 MB Seagate.
The "trying to write bad sector" panic can happen if linux finds a drive
it simply doesn't know how it might possibly read/write. The harddisk
driver is unable to cope with more than 2 drives and/or more than 16
heads. The reason is that the st-506 programming interface only has one
bit for drive identification, and 4 bits for head info. So if linux
sees a disk that has more heads than 16, linux gives up with the above
panic.
If somebody knows how >16 heads are handled on the IO register level,
I'd be interested to know.
> I have partitioned it several
>different ways. I am putting the Linux/Minix partition in a primary slot.
>I have tried the turbo on/off. Any suggestions on what to try. I guess I
>could try putting Linux as hda1, but I don't see how this would solve
>the problem. Please HELP!!!
No, using hda1 shouldn't make any difference. If your controller allows
different sector translations, you might want to re-configure the drive
using fewer heads, although that might then be a problem for the BIOS if
the number of cyliders grow beyond 1024 (linux hasn't got this
particular problem).
Linus
=================
=================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux: system failure - HD format - HELP - SOS
Keywords: Linux HELP system failure
Message-ID: <1992Oct16.145823.29423@klaava.Helsinki.FI>
Date: 16 Oct 92 14:58:23 GMT
References: <wies.719221674@NewsServ>
Organization: University of Helsinki
Lines: 38
In article <wies.719221674@NewsServ> wies@Informatik.TU-Muenchen.DE (Rene Felix Wies) writes:
>
>Well, I got the following error message:
>
> in /usr/src/linux/kernel/chr_drv:
> I did a: touch *.c *.h
> then a: make dep
> followed by a: make
> THE RESULT:
> cc -c tty_io.c
> cc -c console.c
> console.c: In function 'scrup':
> console.c: 360: fixed or forbidden register was spilled
> This may be due to a compiler bug or to impossible asm statements.
> make: ***[console.o] Error 1
You aren't supposed to run "make" by hand in the linux kernel
subdirectories: the makefiles are set up so that a make in the base
directory will compile the kernel. The message you are seeing has to do
with the __asm__ statements in console.c - without optimizations gcc
runs out of registers, and gives up. The correct optimizations and
other compiler flags for the kernel are set up in the main makefile, and
are needed to make a good kernel binary.
Also, you seem to be running an older version of linux (0.96), which has
problems with newer binaries (and also has some serious known bugs
relating to both screen IO and the memory management routines).
Try getting a newer version of linux (0.98.1 is ok, although it has some
problems with busmice and some disk drives). The best way to then make
sure the kernel is recompiled correctly is to set up all parameters
(editing the main makefile to choose keyboard etc), and do a
make clean ; make dep ; make
to get a good kernel Image.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Questions about ...
Message-ID: <1992Oct17.220153.3470@klaava.Helsinki.FI>
Date: 17 Oct 92 22:01:53 GMT
References: <rickm.921017114819@eng.auburn.edu>
Organization: University of Helsinki
Lines: 28
In article <rickm.921017114819@eng.auburn.edu> rickm@eng.auburn.edu (Rick Martindale) writes:
>
>Q1: I am still experiencing Unexpected hd Interrupt. I have read in
> the past to bump up the HD_DELAY. This didnt fix it. Then I read
> to add:
> (void) inb_p(HD_STATUS)
> to read_intr ( in hd.c ). I am running 0.98.1 and the line already
> exist. Is there something else that needs to be done? Would it be
> ok to simply comment out the print for the Interrupt message?
Some drives (notably kalok and some NEC drive) give this message - they
have given it for every single kernel version I've ever put out, and
they seem still to work fine. If you don't see anything which looks like
buffer corruption, commenting out the message is ok.
>Q2: What is required to get ps running under 0.98.1?
There is to my knowledge no 0.98 version of 'ps', but the 0.97.pl6
version should work (but may need recompilation and certainly needs
updating with 'ps U').
>Q3: I am getting a core dump when I attempt a umount. Any Ideas.
Try getting a new umount binary from (for example) the hlu [b|r]ootdisk,
which should hopefully fix this(?). Haven't heard about this particular
problem before, though.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Any mail or fakemail available for linux ?
Message-ID: <1992Oct17.215224.3282@klaava.Helsinki.FI>
Date: 17 Oct 92 21:52:24 GMT
References: <1992Oct9.040601.23881@unlv.edu> <147770002@hplsla.hp.com>
Organization: University of Helsinki
Lines: 19
In article <147770002@hplsla.hp.com> ericb@hplsla.hp.com (Eric Backus) writes:
>
>I don't know the details of what the sticky bit does to a directory on
>a SPARCserver. However, this still appears to be a security hole.
>Here's what you could try to do:
>
> Move someone's mailbox to a different name. Even if noone else can
> read it, you could now create fake mail for the original person.
> Or you could put a non-writable file there to prevent the person
> from ever receiving mail.
With the sticky bit set, you cannot even move the mailbox, so this is
not a problem. Although old versions of linux actually return the wrong
error-value for this (ENOENT instead of EPERM), it has been enforced
since about 0.96c, when somebody pointed this out to me. And 0.98.2
will correct even the error-return (thanks to this thread: I don't think
I had actually tested it out before now :-)
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: ANNOUNCE: 0.98.pl2 is out
Summary: New patches. Again.
Message-ID: <1992Oct18.144546.28249@klaava.Helsinki.FI>
Date: 18 Oct 92 14:45:46 GMT
Organization: University of Helsinki
Lines: 70
[ I already sent this to the mailing-list, nothing new, so skip this if
you already saw it ]
Patch 2 to 0.98 is out - it's available as both full source and as
patches against 0.98.1 at nic.funet.fi: pub/OS/Linux/testing/Linus (and
testing is still unreadable, so you have to cd to it blindly).
patch-2 is >150kB compressed, as it contains several big changes. Most
notable are:
- the new FPU-emulator by Bill Metzenthen. It's bigger than the old
one, but thanks to it, linux fpu emulation is no longer a quick hack,
but a real emulator: it does all the 387(486) math instructions, and
does them much faster than the old emulator + the soft library.
The new math-emulator means that a separate soft-float library is no
longer needed. It also makes even a non-coprocessor system pretty
useful for limited math-calcs - the complex functions are much faster
when they no longer have to be calculated using simple functions, and
even the simpler instructions that my old emulator handled are faster
using the new one.
The size of the new emulator may mean that people who have little
RAM, but do have a coprocessor should probably recompile the kernel
with the emulator disabled.
- various minor mm fixes by me: trapping kernel NULL dereferences,
cleaning up the page table initializations and the 16MB patches, and
various other bugfixes. get_free_page(GFP_ATOMIC) should preserve
the interrupt flag, so malloc() should be safe now - hopefully no
more of the tcp/ip memory management problems.
The NULL pointer trapping may result in errors like:
Unable to handle kernel paging request at address C0000???
Oops: 0000
..... debugging info .....
There were several NULL pointer dereferences in the serial and tty
drivers, which should now be fixed. I've also fixed any other errors
I've seen, but if there are problems in the scsi drivers or similar
things I cannot test, I'd like to hear about them.
- scsi driver changes by Eric Youngdale. Preliminary support for
removable media, and some bug-fixes. Due to white-space problems
with eric's patches, the scsi patches are a bit bigger than
necessary, but they should be ok even though I had to put them in
partly by hand (and being unable to test them...)
- The new tcp/ip patches that were sent to the NET channel not long
ago. Yes, they are alpha, but so is the whole tcp/ip directory, so I
put them in even thought they haven't been extensively tested (and
they did have a serious problem in the ioctl code, which I fixed).
- psaux mouse patches by Dean Troyer, as well as the mouse.wait = NULL
patch.
Before (or after) patching, you should remove the old math-emulator (ie
"rm -rf /usr/src/linux/kernel/math") as it is no longer needed. You
should also do a "make dep" to update dependencies: as usual, I edited
out the dependancy-changes. Do a "make clean", edit the main (and net)
Makefiles to suit your system, and compile.
And finally: I will no longer be making the bootdisks available -
they'll be made by hlu/jwinstead and will probably be boot+root-disks
using lilo, as done on the hlu disks. That may mean that a bootimage
won't be available at once, but most people who want to use the
absolutely newest images probably compile them themselves anyway, so
that shouldn't be a problem.
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: ANNOUNCE: 0.98.pl2 is out
Message-ID: <1992Oct18.224202.14619@klaava.Helsinki.FI>
Date: 18 Oct 92 22:42:02 GMT
References: <1992Oct18.144546.28249@klaava.Helsinki.FI>
Organization: University of Helsinki
Lines: 40
In article <1992Oct18.144546.28249@klaava.Helsinki.FI> I wrote:
> [ deleted ]
>
> - various minor mm fixes by me: trapping kernel NULL dereferences,
...
Oh, boy. Talk about a feature that proved itself. I have never gotten
so many bug-reports so fast: it seems there were quite a few
NULL-pointer problems in the code I hadn't been able to test. Thus
0.98.2 isn't actually very useable unless you have a system very close
to my setup - I don't recommend the faint-of-hearted to try it out.
I guess I should be happy the new feature found problems in the kernel
sources, but I could well have lived with a couple less problems. Main
problem areas seem to be:
- the vhangup() system call - used by newer login-binaries, and
resulting in login getting killed.
- some scsi driver problems (but they should be fixed by the patch eric
already sent out)
- tcp/ip problems - at least three different places where NULL gets
dereferenced (and one is particularly ugly: it does test for NULL,
but does so *after* dereferencing it...)
The vhangup() problem was easy to correct (and excusable: it broke at
least partly due to the new dynamic tty-routines). I'll make some
preliminary testing-patches available that fix that problem, and
includes the scsi fixes.
But the tcp/ip code is a bit worse: I fixed two of the known problems,
but I'd rather use patches from the persons who wrote the code
originally, as there are some other problems in there.. And I can't be
sure I find them all anyway, as I'll never see the problems first-hand.
Just wanted to warn everybody about this aspect of pl2 - the
NULL-pointer finding code is working a bit too well for my taste. I had
hoped there wouldn't be quite this many NULL pointer problems, but at
least they'll be found this way.
Linus
===============================
===============================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: ANNOUNCE: 0.98.pl2 is out
Message-ID: <1992Oct20.090136.963@klaava.Helsinki.FI>
Date: 20 Oct 92 09:01:36 GMT
References: <719518170snx@kerberos.demon.co.uk>
Organization: University of Helsinki
Lines: 16
In article <719518170snx@kerberos.demon.co.uk> alovell@kerberos.demon.co.uk (Anthony Lovell) writes:
>
>Well look on the bright side if you couldn't find the bugs how would they
>get fixed
Oh, yes, the NULL-pointer finding code was definitely a good move: I
have already received patches for (or fixed them myself with the help of
reports sent in by others) at least 99% of the problems, and it seems to
have resulted in at least the tcp/ip code working much better. I now
have reports that X11 runs fine both to and from another machine under
linux with tcp/ip, and I'll make 0.98.3 available in a few days after I
have gotten some more reports. So I'm not complaining about the
problems with 0.98.2 (although others probably are :-), but I would have
been even happier if everything had worked 100% on the first try..
Linus
==============================
==============================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: tgif compiled, but what about SIGBUS?
Keywords: tgif, signals, SIGBUS
Message-ID: <1992Oct20.121054.401@klaava.Helsinki.FI>
Date: 20 Oct 92 12:10:54 GMT
References: <michaelp.719486349@strange> <danielce.719491882@munagin> <1992Oct19.153951.6649@lucrece.robots.ox.ac.uk>
Organization: University of Helsinki
Lines: 22
In article <1992Oct19.153951.6649@lucrece.robots.ox.ac.uk> jon@robots.ox.ac.uk (Jon Tombs) writes:
>
>I think bsd gives a SIGBUS if a user program does a inb() or outb() call,
>this would seem to be more appropriate than SIGSEGV under linux.
Actually, this isn't a good idea: linux would have to check why the
protection error happened, and I don't think that is necessary or even
something we want it to do. The current kernel setup just sees an error
it cannot handle, so it sends a SIGSEGV. No special cases, no chacks
why it happened etc.
One good (or at least better) argument for SIGBUS being included (and
one I have been thinking about) is that a 486 actually has an alignment
trap, which under sysv-386 does seem to result in a SIGBUS (not that I
have tried: just read about it somewhere). I haven't bothered about it,
as I think the alignment trap is disabled under linux anyway. Besides,
I don't see any reason for an alignment fault unless the processor
really isn't able to handle unaligned transfers - but a 486 is perfectly
capable of doing them, even if they are a bit slower. And gcc generally
doesn't generate such code anyway.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: 0.98 and 0.98pl1 won't boot; will 0.98pl2 help?
Message-ID: <1992Oct20.131421.14178@klaava.Helsinki.FI>
Date: 20 Oct 92 13:14:21 GMT
References: <1992Oct20.103029.3560@cs.tu-berlin.de>
Organization: University of Helsinki
Lines: 19
In article <1992Oct20.103029.3560@cs.tu-berlin.de> snake@cs.tu-berlin.de (Harald Schulze) writes:
>When I try to boot Linux 0.98 or 0.98pl1 I get :
>AX <number>
>BX <number>
>CX <number>
>DX<number>
>while the floppy is making lots of noise.
>
>This happens after "Loading..." when I have more than 80 '.' on the screen.
This wouldn't be on a 360kB floppy, would it? Linux won't boot from one,
so don't even try. Use a high-density (1.2M or 1.44M) floppy, and make
sure there are no errors on it: the initial loading sequence is a bit
picky about the floppy quality, and a bad floppy can also result in the
above error-messages. If you get those kinds on messages on a HD floppy,
try a new one, or at least reformat the floppy and re-rawrite linux to
it.
Linus
===========================
===========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Unix Books
Message-ID: <1992Oct21.161022.18125@klaava.Helsinki.FI>
Date: 21 Oct 92 16:10:22 GMT
References: <1992Oct20.004410.24099@athena.mit.edu> <1992Oct21.121703.13670@ifi.informatik.uni-stuttgart.de>
Organization: University of Helsinki
Lines: 37
In article <1992Oct21.121703.13670@ifi.informatik.uni-stuttgart.de> weberj@dia.informatik.uni-stuttgart.de (Weber) writes:
>In article <1992Oct20.004410.24099@athena.mit.edu> jwiegand@moe.eng.temple.edu writes:
>>
>>11. Title: The Design of the Unix Operating System
>> Author: Maurice Bach
>> Publisher: Prentice Hall
>> Edition: 1986
>> ISBN: 0-13-201799-7
>> Comment: An excellent reference on the internals of System V ...
>> This book and the next one are indeed highly technical ...
>>
>I have read in this book and I liked it.
>My question: Is this book compatible with Linux, too (or the other
> way round)?
Well.. It was one of the books I used pretty heavily during early
development, so there are certainly similarities: some of the algorithms
(especially in the filesystem and buffer cache) the book describes are
used in linux, and even function names can be similar. The book does
lack in some areas (networking and job control) due to the sysv(r3)
influence, but it's certainly a good book if you are interested in the
unix kernel internals - I actually used the system call reference in the
book as a check-list when implementing the basic linux system calls
(along with ast's "OS Design and Implementation").
Another book I'd kill for (but haven't bought yet - it's a bit pricey)
is Leffler et al's 4.3BSD internals book ("The Design and Implementation
of the 4.3BSD system and..."). It covers the BSD system the same way
Bach covers sysv, and has some pretty interesting chapters. I haven't
been able to more than skim through it, but Linus says: "get it" if you
can afford to and are interested in the intricacies of the BSD kernel.
Neither of the above books are exactly "linux-compatible" (what a
concept!), but they are the next best thing: good books about systems
that have influenced linux heavily.
Linus
===========================
===========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Q: List "Linux supporting Computers" ???
Message-ID: <1992Oct23.091550.28618@klaava.Helsinki.FI>
Date: 23 Oct 92 09:15:50 GMT
References: <dingelde.719765444@putzl>
Organization: University of Helsinki
Lines: 29
In article <dingelde.719765444@putzl> dingelde@igd.fhg.de (Dennis Dingeldein) writes:
>Hi,
>I just downloaded Linux 0.98.1 Bootdisk and 0.97 Rootdisk
>from nic.funet.fi, transfered the stuff to DOS and executed rawrite
>to write the stuff on disks.
>
>I tried to run Linux on three Machines (2x386 and 1x486) in my company.
>One of them was a Compaq 386.
>The Results were AS BAD AS POSSIBLE
>Linux did not run on ANY MACHINE !
Hmm. While it's entirely possible that linux won't work on the machines
(it does happen), the fact that it doesn't work on *any* of them makes
me wonder about your boot-disk (and possibly root-disk) integrity.
Linux does work on most AT-386's it seems, and the above seems a bit too
unlucky (although at least some Compaq machines are known for doing
things their own way: Compaq has this IBM-complex and thinks it can
change the standards to suit itself. I think it's gotten better).
The easiest way to prove there is no problem with a boot floppy is to
find a computer it boots on: if you cannot, you should make sure you
downloaded the images in binary mode all the way etc. If the bootimage
is corrupted (or only partly written or similar: rawrite seems to have
problems with some machines), the normal result is the reboot you
describe. Don't be fooled by the fact that "Loading..." appears to
work: that is handled by only the first 512 bytes, so even if they are
good, the rest may not be.
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: minix as a V86 task?
Message-ID: <1992Oct23.093614.29238@klaava.Helsinki.FI>
Date: 23 Oct 92 09:36:14 GMT
References: <1992Oct23.031534.4907@cbnewse.cb.att.com>
Organization: University of Helsinki
Lines: 30
In article <1992Oct23.031534.4907@cbnewse.cb.att.com> sph1@cbnewse.cb.att.com (stephen.p.hill) writes:
>I am going to take a class that requires a little Minix
>programming ( either this spring or in the fall ) and I was
>wondering if anyone ever tried to run Minix ( an 8088 version,
>of course, not the 386 version ) under Linux. I realize that
>the best solution would be to convince the teacher to use
>Linux instead of Minix, but Linux does not come with a textbook..
>
>It would be pretty neat if I could run 4 or 5 instances of Minix
>under Linux, but I haven't got a clue if this is possible.
>Anyone with the answer?
Well, this sounded like a fun thing to try, so I tried starting the
minix univeral boot version under the linux DOS-emu, in the hope that it
would work as it uses the BIOS for most things. I'm afraid it doesn't.
It actually gets as far as loading the kernel and printing out the minix
copyright message and asking for the keyboard type.
But after giving the correct keyboard, minix starts to do something to
the DMA registers (I haven't looked at the source - but that's what the
dosemu debugging info would seem to indicate), which the linux
dos-emulator doesn't emulate at all. So when minix starts looping
waiting for something to happen, it just sits there, and I killed it
from another VC.
So, no, it's not possible with the current emulator, and it would
probably take a lot of work to get it working. Not impossible, but not a
trivial project either.
Linus
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: ANNOUNCE: 0.98.pl2 is out
Message-ID: <1992Oct23.110949.4466@klaava.Helsinki.FI>
Date: 23 Oct 92 11:09:49 GMT
References: <1992Oct18.144546.28249@klaava.Helsinki.FI> <1992Oct23.101109.1433@mnemosyne.cs.du.edu>
Organization: University of Helsinki
Lines: 18
In article <1992Oct23.101109.1433@mnemosyne.cs.du.edu> mpevans@nyx.cs.du.edu (Mark Evans) writes:
>
>Is there a simple way to turn this NULL pointer trapping off?
>So I have a machine I can login to
>login: root
>Unable....
>is not much use.
There is a simple patch (removing one test in an if-statement in
memory.c), but it's not a real solution to the problem, so I won't even
post it here (I did post it to the NET channel as I wanted some response
to some other problems with tcp/ip). 0.98.3 will correct all of these
that I have so far gotten reports on (and the pre-version that is
available to limited testers (ie the mailing-lists) corrects 99% of
them). 0.98.3 will be out this weekend, so I'd suggest you wait two
days for it.
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux,gnu.misc.discuss
Subject: Re: Copyright
Message-ID: <1992Oct24.093456.7675@klaava.Helsinki.FI>
Date: 24 Oct 92 09:34:56 GMT
References: <1992Oct23.121845.25080@ringer.cs.utsa.edu> <1c8sihINNqm5@uwm.edu> <seu14eS00j5uAS9XdF@andrew.cmu.edu>
Organization: University of Helsinki
Lines: 33
In article <seu14eS00j5uAS9XdF@andrew.cmu.edu> sh2v+@andrew.cmu.edu (Stephen Hathorne) writes:
>
>Can anyone tell me a little more about the copyright involved with linux?
>I am working on an application, and wish to use linux as the operating
>system, (this will save my client about $500)
>
>I do not intend to charge for the operating system, but I do intend to
>charge for the application, and support.
This is no problem for the actual kernel: if you use linux you just have
to make the sources available for the kernel - the copyleft doesn't
matter for any programs running under linux (even if that would have
been legal, which I doubt, it's not a restriction I would have wanted to
put anyway). Money isn't the problem: if you wish, you can even charge
for the operating system as well - as long as the kernel source is free
and available from you once he's bought the binary.
There might be some problem with the C library, however. Most of it is
from the GNU libc.a, and as such is under the GLPL - this doesn't mean
you have to give away your sources, but it does mean that you have to
give the client a chance to re-link your binaries against a newer (or
maybe just his own) version of the library. I think it's actually ok if
you use the shared libraries with jump-tables (as then your binary
doesn't contain any actual copylefted code), but maybe somebody who
knows more about the GLPL should comment (which is why I crossposted to
gnu.misc.discuss - hope this doesn't turn into yet another flamewar).
Exactly due to these kinds of problems I made the actual linux low-level
library routines totally free (ie the kernel interface hooks). So
programs using those will not be encumbered, but they include only the
basic unix system calls, and any real program uses many GLPL'd routines.
Linus
===========================
===========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Problem copying files with holes to msdos file system
Message-ID: <1992Oct24.095215.8096@klaava.Helsinki.FI>
Date: 24 Oct 92 09:52:15 GMT
References: <9229816.15059@mulga.cs.mu.OZ.AU>
Organization: University of Helsinki
Lines: 23
In article <9229816.15059@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
>I've mounted my DOS partition using "mount -t msdos /dev/sda1 /dos",
>and most things work fine. But I have had trouble copying some large
>from the Minix file system to the DOS file system. When I try to
>copy my boot image file across, using "/bin/cp /linux-0.97.1 /dos/linux-97.1",
>it goes into an infinite loop. I can't kill the process even with kill -9.
>The hard disk is being continually accessed, and performance on the
>other virtual consoles is terribly slow. "ls -l /dos/linux-97.1" shows
>the file size to be only 3072 bytes.
You are right: older versions of the msdos fs have problems with holes
in files. The easy solution is to upgrade: 0.98.x shouldn't have this
bug.
>Another problem of unknown cause: I tried moving a few large files from
>the dos file system to the minix file system using /bin/mv, and the
>system spontaneously rebooted in the middle of executing the command.
>I don't seem to be having much luck at the moment :-(
This one too seems to be gone: I just copied over 1M+ files with 'mv' to
check it out, and it doesn't happen for me. Upgrade time.
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: will linux use swap partition AND swap file at the same time
Message-ID: <1992Oct24.181041.17174@klaava.Helsinki.FI>
Date: 24 Oct 92 18:10:41 GMT
References: <1cc0gqINN673@usenet.INS.CWRU.Edu>
Organization: University of Helsinki
Lines: 28
In article <1cc0gqINN673@usenet.INS.CWRU.Edu> mal11@po.CWRU.Edu (Matthew A. Lewis) writes:
>
>I need 16MB of swap and my partition is only 8MB.
>Can I make an 8MB swap file or do I have to disable the swap
>partition and make a 16 MB swap file??????????
No problem if you are running a relatively recent kernel: you should be
able to use both a swap-partition (for good performance) and a swap-file
(for the overflow that won't fit into the partition) at the same time.
Just do:
- create the swapfile (needs to be done only once):
# dd if=/dev/zero of=swapfile bs=1024 count=8192
# mkswap swapfile 8192
- enable swapping (usually at bootup):
# swapon /dev/hdXX
# swapon swapfile
Note that you had better enable the partition first - linux doesn't do
any clever swap-space striping or similar, but instead uses up the
swap-pages in the order they were installed. So enabling the partition
first means that it gets "preferred status", which is generally what you
want (as it's noticeably faster to swap to a partition).
Linus
=================
=================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Linux - the future?
Message-ID: <1992Oct25.172207.11981@klaava.Helsinki.FI>
Date: 25 Oct 92 17:22:07 GMT
References: <1992Oct25.144134.19612@cs.hw.ac.uk>
Organization: University of Helsinki
Lines: 88
In article <1992Oct25.144134.19612@cs.hw.ac.uk> scottd@cs.hw.ac.uk (Scott Dunn) writes:
>
>How do you, Linus, see Linux developing?
>I have to admit that this is the one concern I have always had about Linux.
>You are, I think I'm right in saying, a student. Developing Linux can't be
>your main concern at this point in time, unless of course you've managed to
>tie it in with your course.
Actually, it's so far been the other way around: studies haven't been my
main concern at this point of time unless I've been able to tie them in
with my linux-hacking. Only half-joking - it really isn't linux that
has lost time due to other things..
> Do you intend taking it as far as 1.0 and then
>leaving it in the hands of the Linux community to take it further?
1.0 has never been any magic number - I don't intend to stop there, and
the only reason I have delayed it is because there has always seemed to
be yet another important feature or bug-fix "any day now". My current
setup is much better than I originally envisioned 1.0 - but even that
doesn't mean I'm thinking of quitting.
There was some talk on the mailing-lists (actually, just one list back
then) around version 0.12 about me stepping down in case somebody else
(or some group like the FSF) wanted the job, but nobody seemed even
slightly interested, and I haven't heard any complaints about the
current state of affairs yet. It seems people prefer having somebody as
a final arbiter on what goes in and what doesn't, and I've been the
natural choice so far despite some of the problems (mostly due to
lacking hardware).
>Are there plans to make it SVID (System V Interface Definition) binary
>compatible?
I've been idly thinking about it: the biggest problem has been lack of
docs and programs. In any case, I don't feel binary compatibility is
very high on my list, and I'd rather delay it until the kernel seems to
be a bit more stable ("stable" in the meaning not-changing as opposed to
"crashing every minute"). I'm not against binary standards, but I'd
implement it more as a shell around the "real" linux kernel than as a
integral part of the kernel.
I've always been pro-standard: mostly POSIX, as that has meant porting
is easy, and that has been the only thing I've been interested in, as I
don't have any sysvr4 binaries anyway. I don't think this will change:
linux will probably be able to accomodate future standards faster than
systems that don't come with source code. After all, being freely
available has resulted in the current system in "record time" (or then
I'm just such a helluva programmer - take your pick :-)
>What features are missing from Linux?
On a user level, the worst actual missing features are probably related
to memory management: the linux memory manager is still just three (not
even very big) files, and while it's clever, it's not very general. So
things like shared memory and a real mmap() are still not there,
although I've been looking into it for some time now.
Internally, the socket code isn't very well integrated with the rest of
the kernel - I'd like something more general. But there aren't any
major features missing: the networking code may not be quite stable yet,
but that's just a matter of time, as the basic things are there.
>If you, Linus, are unable or unwilling to continue developing Linux
>in the future would the handover of Linux to FSF be an option?
The day people think linux would be better served by somebody else (FSF
being the natural alternative), I'll "abdicate". I don't think that
it's something people have to worry about right now - I don't see it
happening in the near future. I enjoy doing linux, even though it does
mean some work, and I haven't gotten any complaints (some almost timid
reminders about a patch I have forgotten or ignored, but nothing
negative so far).
Don't take the above to mean that I'll stop the day somebody complains:
I'm thick-skinned (Lasu, who is reading this over my shoulder commented
that "thick-HEADED is closer to the truth") enough to take some abuse.
If I weren't, I'd have stopped developing linux the day ast ridiculed me
on c.o.minix. What I mean is just that while linux has been my baby so
far, I don't want to stand in the way if people want to make something
better of it (*).
Linus
(*) Hey, maybe I could apply for a saint-hood from the Pope. Does
somebody know what his email-address is? I'm so nice it makes you puke.
Don't worry, though: this is just my net-personality, and in real life I
kick furry small animals for fun.
===================
===================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: 0.98.3 is late ...
Message-ID: <1992Oct26.050726.2504@klaava.Helsinki.FI>
Date: 26 Oct 92 05:07:26 GMT
Organization: University of Helsinki
Lines: 16
... as you probably all have noticed. I've been up all night writing
this report for the "CS Course from Hell" (*), and haven't had time to
play with linux. I'll get it done tonight if I can keep awake that
long.
In case anybody still wonders, 0.98.3 mainly fixes the NULL pointer and
most of the serial line problems. I also started to remove some of the
more unnecessary cli-sti pairs (where races could be avoided by doing it
some other way), so it's possible interrupt latency is better, but I
doubt it's noticeable.
Linus
(*) Well, they call it "ATK-suunnittelun laboratorioty|", but they
aren't fooling anybody.
================
================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: 0.98.3 finally available
Message-ID: <1992Oct27.040101.28497@klaava.Helsinki.FI>
Date: 27 Oct 92 04:01:01 GMT
Organization: University of Helsinki
Lines: 10
0.98.3 is available at nic.funet.fi: pub/OS/Linux/testing/Linus as diffs
against 0.98.2 (linux-0.98.patch3.Z) and against the pre-release that
was announced on the mailing-lists (pre-final.diff.Z). I haven't
uploaded the complete sources yet, so diffs are all there is: I'll
upload the full sources once I've gotten some more sleep.
0.98.3 corrects a lot of NULL-pointer bugs, as well as some other
problems (notably serial lines). Hope this release will be stable,
Linus
=====================
=====================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: I can malloc more memory than I have.SKIP
Message-ID: <1992Oct27.105511.17819@klaava.Helsinki.FI>
Date: 27 Oct 92 10:55:11 GMT
References: <1992Oct26.083011.17192@fys.ruu.nl> <1992Oct26.180801.28536@sfu.ca> <1992Oct27.124302.90427@vaxc.cc.monash.edu.au>
Organization: University of Helsinki
Lines: 30
In article <1992Oct27.124302.90427@vaxc.cc.monash.edu.au> johnhm@vaxc.cc.monash.edu.au writes:
>
> I think the problem is more general than just running out of virtual memory.
>It seems as though code that runs in the kernal can realy hog the the machine
>to the exclusion of all else.
> For instance, when running X11perf without a coprocessor the machine will seem
>to grind (almost) to a halt during some of the tests (probably ones using
>circular functions heavily). Lack of memory doesn't seem to be the problem
>here as there is no swapping going on (which top confirms whenever it gets a
>chance to run). It seems a bit strange if the kernal is blocking other processes
>even if it's just doing floating point emulation. I wonder if this extends to
>everything the kernal does?
While it's true that a kernel process won't be rescheduled while it
still runs, this should be no problem: all the system calls, traps and
interrupt handlers are designed to cope with that (although there may
actually be some busy waiting in the SCSI-driver). The reason x11perf
seems to bring the machine to it's knees is not that the kernel hogs all
the time, but because X11 itself is busy calculating things - while the
X server does it's calculations, it won't do other screen updating...
The core-dumping mis-feature when running out of swap is a pity - I
might try to make this a special case so that no core will be generated
for this case (you don't do much with a core-file anyway: it wasn't
exactly a program bug that resulted in it being terminated). In the
meantime, setting the core-size to 0 (ulimit -c 0) is the preferred
option unless you are actively debugging something. Do it in your
.profile, and you'll never see another core again..
Linus
======================
======================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: ANNOUNCE: linux-0.98.3
Message-ID: <1992Oct27.194952.14193@klaava.Helsinki.FI>
Date: 27 Oct 92 19:49:52 GMT
Organization: University of Helsinki
Lines: 59
Ok, I already sent out an announcement last night, but due to the time
(6AM over here) I wasn't really in a mood to write a real annoucement.
Here it is.
linux-0.98.3 is available by anonymous ftp at least on nic.funet.fi:
pub/OS/Linux/testing/Linus, both as context diffs against 0.98.2 and the
pre-version of 0.98.3 and as complete source. The complete source
package was done by directly applying the diffs - this means that the
Makefile dependancies are probably not 100% up-to-date as I remove those
from the diffs. It shouldn't be any problem, and you can always do a
"make dep ; make clean" before actually compiling the kernel.
0.98 pl3 fixes several bugs, and should remove all known NULL-pointer
problems that made 0.98.2 unusable for most people. In addition to the
NULL pointer fixes, the following things have changed:
- removed most of the cli-sti pairs in the filesystem code by rewriting
the locking routines to use a different algorithm, possible due to
the rewritten wait-queue code that I did back in 0.96c or so.
Interrupt latency should be better on slow machines, but I don't know
if it's noticeable.
- Minor 387-emulation fixes by Bill Metzenthen - only noticeable under
special conditions.
- Corrected various error-returns in the fs (thanks to Bruce Evans for
running some error diagnostics). Error messages when opening (and
renaming etc) files that had a non-directory in the path were wrong,
and should be ok now (ie giving ENOTDIR instead of EACCESS or ENOENT).
Some other problems reported by Bruce fixed.
- Changed the interface for some fs-related functions due to cleaning
up super-block handling. Most noticeably, iget() and related
functions no longer specify the inode with a device and inode number,
but instead with a super-block pointer and inode number. This is
more logical, and should make unnamed devices (ie internal
filesystems like nfs and /proc) cleaner. Also note that the calling
sequence for sb->s_op->put_inode() also has changed since 0.98. This
is of interest only if you are writing filesystem drivers..
- ASK_SVGA was broken in 0.98.2 - it should be ok now.
Also, various minor fixes as usual. No new features, but I hope 0.98.3
will be a lot less bug-prone due to the changes since 0.98.1. Some
minor tcp/ip corrections (but most of them were in the pre-release), and
I removed a race-condition in the tty-handling code.
Note that people who use math without a co-processor should certainly
upgrade to 0.98.3: the new emulator is much better than my original one
both in speed and accuracy/exception handling. x11perf is very much
bearable now even without a 387, and things like ray-tracing etc
shouldn't be a problem any more. It's slower than hardware fp, of
course, but at least it works.
The new emulator also means there is no reason for a separate soft-float
library, so I'd assume that will be gone in the next gcc release for
linux.
As usual, a new kernel version probably means you'll have to recompile
'ps' and friends. But at least the same 'ps' sources that worked for
0.97.6 should still work.
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: MAJOR bug in mount in 0.98.3
Message-ID: <1992Oct29.121938.16664@klaava.Helsinki.FI>
Date: 29 Oct 92 12:19:38 GMT
Organization: University of Helsinki
Lines: 66
Sorry everybody, but pl3 has a major bug in mounting related to the
caching of inodes - they are searched according to inode number and the
super-block they are associated to (so far so fine), but the super-block
info is not correctly updated when mounting/umounting a filesystem.
This is not normally noticeable (bad excuse) as most people (including
me) mount things just once, but if you umount and remount something, it
can lead to MAJOR filesystem corruption.
Thanks to hlu, who found this (sadly destroying his fs in the process..)
The fix is in linux/fs/inode.c, in the function 'fs_may_mount()'. It
looks like this:
----- "patch" follows -----
int fs_may_mount(dev_t dev)
{
struct inode * inode;
for (inode = inode_table+0 ; inode < inode_table+NR_INODE ; inode++) {
if (inode->i_dev != dev)
continue;
if (inode->i_count || inode->i_dirt || inode->i_lock)
return 0;
inode->i_dev = 0;
+ inode->i_sb = NULL;
}
return 1;
}
----- end of "patch" -----
ie, just add the "inode->i_sb = NULL;" line to the function. That
should fix the problem.
Another problem (also found by hlu) is in linux/kernel/chr_drv/serial.c,
where an 'outb()' statement has the order of the argumebts mixed up. The
offending line is in the function set_modem_info(), line 778, and it
looks like this:
----- begin "patch" -----
default:
return -EINVAL;
}
! outb(UART_MCR + port,control);
return 0;
}
******
default:
return -EINVAL;
}
! outb(control, UART_MCR + port);
return 0;
}
----- end "patch" -----
ie, just swap the 'control' and 'UART_MCR + port' arguments. Neither of
the above is a "real" patch in that you have to patch it by hand, but I
haven't had time to do those yet (and I'll try to find some other bugs
while I'm at it). But if you have 0.98.3, *PLEASE* apply them, or use
an older version.
Sorry for the new bugs,
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Strange minix fs problem: duplicate core files in directory!
Message-ID: <1992Oct30.155235.18870@klaava.Helsinki.FI>
Date: 30 Oct 92 15:52:35 GMT
References: <1992Oct30.050149.28125@cheshire.oxy.edu>
Organization: University of Helsinki
Lines: 40
In article <1992Oct30.050149.28125@cheshire.oxy.edu> rafetmad@cheshire.oxy.edu (David Giller) writes:
>I just ran into a strange problem with the minix filesystem. When
>dumping core files under X, linux created two files (different, not
>identical) called "core" in my home directory.
>
>Here's the whole explanation:
>
>I installed SLS 0.98 a week ago, and have since patched the kernel up
>to 0.98.3. Rebooted, did an fsck, and started up X.
>
>I created a 4Mb swapfile, and swapon'ed it. I started up about 10
>clients.
>
>Then, for fun, I did a swapoff on the swapfile [ deleted ]
Ok, it's due to a race-condition in the filesystem - I haven't bothered
to fix it for the simple reason that it almost never happens (and it's
bothersome to fix completely), but the above sure is one way to make the
system have some problems. Doing a "swapoff" when you don't really have
enough memory isn't a good idea, although nothing should really break
(linux tries very hard to stop swapping by writing out executable pages
etc - that's why you get all the disk accesses. And as you noticed,
some of the programs may be killed off).
You can create several files with the same name in the same directory
just by stressing the system very hard and trying to create files with
the same name. It's a harmless way to have some fun on your system: the
files are distinct but have the same name so you could possibly confuse
some programs with it. You can delete them one-by one, or simply rename
them: doing a rename on the name will rename the file that is first in
the directory, while the other will still have the old name. It's fun
to mess with the minds of innocent programs by doing these kinds of
stunts - has anybody tried tarring such a directory?
Note that it isn't exactly easy to create these kinds of duplicate
names: you really have to swap pretty badly. I guess I should document
it and add it as a "feature" to linux: it's harmless enough that I
probably won't try very hard to get it corrected.
Linus
========================
========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Strange error with 0.98.3 and X11
Message-ID: <1992Oct30.155953.19088@klaava.Helsinki.FI>
Date: 30 Oct 92 15:59:53 GMT
References: <1992Oct30.120931.3085@ultb.isc.rit.edu>
Organization: University of Helsinki
Lines: 16
In article <1992Oct30.120931.3085@ultb.isc.rit.edu> axi0349@ultb.isc.rit.edu (A.X. Ivasyuk) writes:
>
>I'm getting a strange error when I exit X and it restores the text screen.
>It says, "ERROR: wm-FPU-emu is not RE-ENTRANT!". This doesn't stop X from
>running, but I'm wondering what this is all about...
Yes, there is a bug with respect to re-entrancy in the new
math-emulator. It has to do with several emulator-instances being
active at the same time due to demand-loading or swapping, and might be
a problem for some (but it's timing-dependent as well, so you won't
necessarily see it..). I hope to have it fixed for the next release,
but it shouldn't really break too much software even now. X11 is more
of a problem than most things due to the fact that most people swap a
lot more under X than they normally do.
Linus
============================
============================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: [BUG]: (seems so ...) 0.98pl3
Message-ID: <1992Oct31.220649.27337@klaava.Helsinki.FI>
Date: 31 Oct 92 22:06:49 GMT
References: <1992Oct31.051350.1188@utstat.uucp>
Organization: University of Helsinki
Lines: 23
In article <1992Oct31.051350.1188@utstat.uucp> rafal@utstat.uucp (Rafal Kustra (summer student)) writes:
>Moving to .98pl3, from .97pl4 couses TeX to abort with:
>No inode #/device # in parent directory.
As a rought guess, I'd assume this is with an old binary that tries to
read the directories "by hand" instead of using the readdir() system
call. This happens if it was compiled with something before gcc-2.2.2,
so I thought it wouldn't break anything to disallow that in the new
release. As it turns out, more people are using old binaries than I
though, but I won't re-enable it: reading a directory is not a good idea
and will break on any non-minix filesystems anyway.
So the fix is probably just to recompile TeX or get a newer binary from
some place (but I haven't kept up with TeX: no diskspace). The same
problem also seems to plague some kermit binaries - the symptoms seem to
be that "set line" doesn't work as expected.
You can also see the new behaviour more easily by just doing a "cat ."
using both the old and new linux kernels. With the old kernels, this
results in a messy display of the directory contents on a minix-fs,
whereas 0.98.3 gives the error message "cat: .: Is a directory".
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: SLS 0.98p1 vs Logitech Busmouse (death via wake_up())
Message-ID: <1992Oct31.231854.28578@klaava.Helsinki.FI>
Date: 31 Oct 92 23:18:54 GMT
References: <ingima.720570541@kakwa.ucs.ualberta.ca>
Organization: University of Helsinki
Lines: 29
In article <ingima.720570541@kakwa.ucs.ualberta.ca> ingima@ee.ualberta.ca (Darin Ingimarson) writes:
>
> Well, I haven't got this beat, but I'm far from giving up. Many thanks
>to Bob Kirkpatrick for his help on this. Here is what I've found out so far:
>
> The logitech mouse driver snuffs it in the mouse_int() routine at the
>wake_up() call. What I am humbly requesting is someone who knows a bit more
>about the mouse driver and Linux scheduling to answer a couple of questions for
>me before I get back at it (I've written many a device driver and done lots of
>system level bughunting in a UNIX-like RTOS, so I'm not a complete techno-
>turnip... just not much experience with things like select(), *NIX interprocess
>security, etc.).
>
> It seems to me (from perusing Linus' source) that this wake_up() call
>suggests to the scheduler that it might want to wake up any proceses waiting
>on a mouse interrupt. Why would wake_up() die if no processes are waiting
>on the interrupt? Shouldn't wake_up() just see that nothing is waiting and go
>on with things?
wakeup() works fine even if there aren't any jobs on the queue: this
particular problem is due to there being *bogus* jobs on the queue, as
the wait-queue pointer is never initialized to NULL in 0.98.1.
The easy fix is just to initialize the wait-queue correctly, or indeed
just get 0.98.3 which does it correctly. Also, using new versions of
LILO will result in the kernel bss being automatically cleared, and the
problem goes away.
Linus
============================
============================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: linux-0.98.3 termcap problem
Message-ID: <1992Nov1.101439.10943@klaava.Helsinki.FI>
Date: 1 Nov 92 10:14:39 GMT
References: <1992Nov1.004828.6310@afterlife.ncsc.mil>
Organization: University of Helsinki
Lines: 18
In article <1992Nov1.004828.6310@afterlife.ncsc.mil> jepstei@afterlife.ncsc.mil (John Epstein) writes:
>
>QUESTION: Besides fs and math emulation, was termcap
>supposed to affected by 0.98.2 or 0.98.3
>I assume null-pointer would generate an error.
Arggh. Yes, the kernel did change some terminal info in 0.98.3 - namely
the standard TERM variable. Instead of using the "con80x25" etc names
(which resulted in terrible /etc/termcap files), 0.98.3 initializes TERM
to be simply "console". The terminal size is available from the termios
size structure, and is no longer encoded into the terminal type name.
So if you seem to have problems with termcap, make sure you have an
entry for "console" which essentially looks like vt100 or vt220. That
should be the default (well, it was in *my* termcap even before I did
the changes to 0.98.3), but it may not be true of all systems.
Linus
=======================
=======================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: QUERY: raw floppy devices?
Message-ID: <1992Nov3.104745.13480@klaava.Helsinki.FI>
Date: 3 Nov 92 10:47:45 GMT
References: <2AF55E71.5AA1@tct.com>
Organization: University of Helsinki
Lines: 14
In article <2AF55E71.5AA1@tct.com> chip@tct.com (Chip Salzenberg) writes:
>Is there a technical reason not to support /dev/rfdX devices? It
>seems like a Bad Thing to force one-time floppy accesses (like, say,
>disk copies with "dd") into the buffer pool.
No technical reason unless you count simplicity. When I wrote the
original drivers I didn't want to bother with both raw and buffered
access, so I settled for just the buffered routines. I haven't seen
enough reason to regret that yet: using the fs buffers does fill them up
unnecessarily in some cases, but I haven't really found it to be a
bother (mostly the reverse: no need to bother about blocking factors for
good floppy speed etc).
Linus
==========================
==========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: USENET Readership report for Oct 92
Summary: edited for c.o.linux
Message-ID: <1992Nov3.125211.20525@klaava.Helsinki.FI>
Date: 3 Nov 92 12:52:11 GMT
Organization: University of Helsinki
Lines: 54
Ok, I don't know if anybody was very interested last month either, but
in case people want to know and don't read the news.lists group, here is
the latest (edited) popularity info. Additionally, linux once more
showed up in the top-40 lists in both volume and per-reader cost.
This month yet another milestone was reached: note the "Recent traffic"
fields (both in kilobytes and number of messages): c.o.linux is actually
more active than alt.sex according to newsstat. c.o.linux was nr 31
in traffic volume in kB - actually the biggest non-binary "technical"
group it would seem.
Linus
----------
This is the edited set of data from the USENET readership report for Oct 92.
Explanations of the figures (and the full lists) can be found in 'news.lists'.
+-- Estimated total number of people who read the group, worldwide.
| +-- Actual number of readers in sampled population
| | +-- Propagation: how many sites receive this group at all
| | | +-- Recent traffic (messages per month)
| | | | +-- Recent traffic (kilobytes per month)
| | | | | +-- Crossposting percentage
| | | | | | +-- Cost ratio: $US/month/rdr
| | | | | | | +-- Share: % of newsrders
| | | | | | | | who read this group.
V V V V V V V V
1 190000 5837 90% 10 158.1 100% 0.00 12.1% news.announce.newusers
2 160000 4971 83% 1002 1958.2 17% 0.02 10.3% misc.jobs.offered
3 160000 4965 82% 1666 2087.5 36% 0.02 10.3% misc.forsale
4 130000 4015 68% 1752 4192.5 41% 0.04 8.3% alt.sex
5 120000 3855 84% 6 262.9 67% 0.00 8.0% news.answers
...
20 75000 2331 87% 1294 2465.0 16% 0.05 4.8% comp.lang.c
...
94 41000 1289 84% 90 120.8 30% 0.00 2.7% comp.unix.misc
...
114 39000 1197 77% 1251 2943.9 5% 0.11 2.5% comp.unix.bsd
...
171 33000 1016 86% 593 928.1 13% 0.05 2.1% comp.unix.ultrix
...
256 27000 842 72% 2890 4755.9 4% 0.24 1.7% comp.os.linux
...
279 26000 801 83% 880 1465.3 8% 0.09 1.7% comp.unix.aix
...
297 25000 784 82% 23 35.4 9% 0.00 1.6% comp.os.misc
...
385 22000 690 83% 163 1094.1 3% 0.08 1.4% comp.os.minix
...
543 18000 554 49% - - - - 1.2% comp.unix.pc-clone.32bit
...
689 15000 478 76% 526 887.8 1% 0.09 1.0% comp.os.coherent
...
1640 1600 49 10% 13 137.4 0% 0.02 0.1% de.newusers
====================
====================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.unix.bsd,comp.os.linux
Subject: Re: Port of new Linux math emulator to 386bsd?
Keywords: math emulator, port
Message-ID: <1992Nov4.111732.9703@klaava.Helsinki.FI>
Date: 4 Nov 92 11:17:32 GMT
References: <1992Nov4.021453.22896@citec.oz.au>
Organization: University of Helsinki
Lines: 16
In article <1992Nov4.021453.22896@citec.oz.au> sgccseh@citec.oz.au (Steve Hocking) writes:
>
> Looking at the latest Linux release and user comments on it, it
>appears that a new math emulator has been written which is more complete and
>accurate, plus about 2x faster. Does anybody have plans to port this to
>386bsd (since we got the original emulator from Linux anyway)?
The problem is the copyright: it's copylefted code by Bill Metzenthen,
so you cannot distribute it under the 386bsd copyright. The original
emulator I wrote was also originally copylefted, but I gave Bill and
Lynne the right to use it under 386bsd (the copyright was changed to
something like "freely usable for the 386bsd and linux projects").
You'd have to ask permission from Metzenthen - his email address can be
found in the sources.
Linus
============================
============================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Free UNIX for sale
Message-ID: <1992Nov4.162315.26780@klaava.Helsinki.FI>
Date: 4 Nov 92 16:23:15 GMT
References: <73559@hydra.gatech.EDU> <1992Nov4.140106.3873@fwi.uva.nl>
Organization: University of Helsinki
Lines: 16
In article <1992Nov4.140106.3873@fwi.uva.nl> stolk@fwi.uva.nl (Bram) writes:
>gt8134b@prism.gatech.EDU (Howlin' Bob) writes:
>>
>> --> 386BSD Version 0.1 & LINUX Version 0.96...............$100 <--
>
>Gee, Linus and other contributors,
>I dont know about you, but I would be pissed off, if someone
>started making money on the stuff I worked so hard at.
Why be pissed off? It's really a compliment. And believe me: getting
money may be fun, but when you get T-shirts, virtual beer, book offers
and enough money to pay off your computer, *even without asking for it*
(dropping a few hints, maybe ;-), it's worth a lot more. Hey, I might
no get rich on linux, but I'm certainly being poor with style, eh?
Linus
=========================
=========================
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Newsgroups: comp.os.linux
Subject: Thanks...
Summary: finally paid off my computer
Message-ID: <1992Nov5.094730.28084@klaava.Helsinki.FI>
Date: 5 Nov 92 09:47:30 GMT
Organization: University of Helsinki
Lines: 16
Just a quick note to say "THANKS" to everybody - today I was able to
finally pay off my computer using money collected by hpa (Peter Anvin)
from various people. The collection brought in USD $750, and together
with some other donations (including a fim 1000 EuroCheque) I was able
to pay the final rate today. I'd also like to thank everybody else who
has sent me either money or any other encouragement (ranging from
postacards and T-shirts (!) to beer-money and actual beer).
I'm not making a "hall of fame" of people who have paid me money: I
might forget somebody (who'd hate me for the rest of his life), and
anyway, contributions in the form of patches/bug-reports etc have been
at least as valuable (and I haven't kept track of those either. Shame
on me). You know who you are,
thanks,
Linus
================================
================================
################################
Reference in New Issue View Git Blame Copy Permalink