Path: sparky!uunet!sun-barr!ames!agate!agate!usenet
From: torva...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.archives
Subject: [comp.os.linux] Linux v. 0.97 is out
Followup-To: comp.os.linux
Date: 3 Aug 1992 07:44:10 GMT
Organization: University of Helsinki
Lines: 102
Approved: a...@soda.berkeley.edu
Distribution: world
Message-ID: <15io4aINN89q@agate.berkeley.edu>
References: <1992Aug1.150838.11254@klaava.Helsinki.FI>
NNTP-Posting-Host: soda.berkeley.edu
Summary: new version release
X-Original-Newsgroups: comp.os.linux
X-Original-Date: 1 Aug 92 15:08:38 GMT
Archive-name: auto/comp.os.linux/Linux-v-0-97-is-out
[ 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
Newsgroups: comp.os.linux
Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!menudo.uh.edu!lobster!nuchat!buster!uhura1!bryan
From: br...@uhura1.uucp (Bryan Curnutt)
Subject: Linux 0.97 kernel compile problems
Message-ID: <1992Aug3.062434.1600@uhura1.uucp>
Keywords: 0.97 kernel
Reply-To: bryan%uhu...@uunet.uu.net
Organization: Stoner Associates, Inc./DREM Incorporated, Houston Texas
References: <1992Aug1.150838.11254@klaava.Helsinki.FI>
Date: Mon, 3 Aug 1992 06:24:34 GMT
Lines: 58
Okay, after Linus' announcement and Ted's subsequent notice of
availability on tsx-11, I grabbed the "complete source-tree"
(linux-0.97.tar.Z) via ftpmail from tsx-11. I've had a few
problems trying to get it to compile, and I'd appreciate any
pointers on what I'm doing wrong. (I'm starting out with an
MCC-Interim 0.96c distribution, with patches 1 and 2, I've
compiled the 0.96c kernel at all patchlevels with no problems.)
First of all,
Linus Benedict Torvalds 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.
>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?
(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.
So far the problems I've seen look easy to fix, in and of themselves,
but they worry me because they mean the kernel won't compile as-is,
which means no one has tested it -- at least, the people who have
tested it must have different files that I do.
Should I go ahead and put the "-I" option in the SCSI makefile, and
define my own struct stat, and try to compile from there, hoping that
everything will work out OK in an apparently untested source tree?
Should I wait for some patch to address these problems? Or should
I be whacked upside the head and pointed toward the appropriate README
file?
Thanks for any (polite) suggestions,
--
Any opinions above are mine, and do not necessarily reflect the views of SAI.
Bryan Curnutt | "I hope that UNIX is more like my diner
bryan%uhu...@uunet.uu.net | than like McDonald's." -- Doug McIlroy
Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
From: torva...@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.1...@uhura1.uucp> bryan%uhu...@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
Newsgroups: comp.os.linux
Path: sparky!uunet!zaphod.mps.ohio-state.edu!menudo.uh.edu!lobster!buster!uhura1!bryan
From: br...@uhura1.uucp (Bryan Curnutt)
Subject: Re: Linux 0.97 kernel compile problems
Message-ID: <1992Aug5.025409.28178@uhura1.uucp>
Keywords: 0.97 kernel
Reply-To: bryan%uhu...@uunet.uu.net
Organization: Stoner Associates, Inc./DREM Incorporated, Houston Texas
References: <1992Aug1.150838.11254@klaava.Helsinki.FI> <1992Aug3.062434.1600@uhura1.uucp> <1992Aug3.162747.25511@klaava.Helsinki.FI>
Date: Wed, 5 Aug 1992 02:54:09 GMT
Lines: 43
In article <1992Aug3.162747.25...@klaava.Helsinki.FI> torva...@klaava.Helsinki.FI (Linus Benedict Torvalds) writes:
>
>Lasu already sent out a copy of the README he wrote
Yes, thank you! This solved all of my kernel compilation problems,
and I'm much happier now. Life is once again beautiful, the fragrance
of flowers fills the air once more, and the birds are singing again.
I would probably have stumbled over the README file eventually, but
I rely heavily on the posted announcements to tell me where things
are because it takes up to five days (usually two or three days, but
I've seen up to five) to get a directory listing via ftpmail, and
then more time to actually retrieve the files.
>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.
Ah. I misunderstood, then, in thinking that include/sys was for
kernel-specific things.
Who writes the "user-level" files? Does each Linux root-filesystem-
implementer, i.e. the person who puts together a Linux distribution,
write his own include files? Are these files considered part of the
operating system, or is creating these files part of porting a compiler
to the system? Just curious...
>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,
This was indeed the problem. I needed both the /usr/include files
that came with the MCC-Interim distribution, and the /usr/include/linux
files that came with linux-0.97.tar.Z.
Thanks for your help, guys!
--
Any opinions above are mine, and do not necessarily reflect the views of SAI.
Bryan Curnutt | "I hope that UNIX is more like my diner
bryan%uhu...@uunet.uu.net | than like McDonald's." -- Doug McIlroy