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.

First cut at core-dumping.  Also, do more dynamic boottime memory
allocation, rather than allocating data structures statically.

Allocate task structures at run-time rather than having a big array of
them.

First "obsolete" system call.  The old "stat()" system call was too
limited, due to "struct stat" having various 16-bit fields etc (notably
inode numbers).  We make a new stat() function, and keep the old one
around as "old_stat()" for binary compatibility.

We also need a bigger "utsname" to hold real node names.

Whoo! NR_OPEN is now 32 rather than 20.

itimer() support driven by X11 adoption (Darren Senn).

gcc starts using fsqrt, so that gets added to the FP emulation.  We're
still basing that on my trivial code.

[Original changelog below]

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

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

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

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

and X11 text-mode restoration.  Thanks to Rick Sladkey for finding the
dup2() bug.

More VFS cleanups.  Minixfs code reorganized to be more logical, and
split up into a few new files.

SCSI support!!

 - Drew Eckhardt does the SCSI stuff, and does the ST01/ST02 lowlevel
   driver.

 - Ultrastor driver by David Gentzel.

 - Tommy Thorn shows up again.  He did the Danish keyboard tables, now
   he does the AHA 1542 driver.  Ten years later we ended up being
   co-workers at Transmeta ;)

First networking code appears: X11 port needs UNIX domain sockets, and
thus the "socketcall()" system call.  It's not really meant for real
networking, although the code will eventually evolve to support that.
Which explains some of the bad early decisions..  ;)

Werner Almerberger starts taking over floppy driver maintenance.  Thank
Gods!

Johan Myreen translates my assembly-level keyboard driver into C code,
and adds support for diacriticals.

OMAGIC a.out format support

Syslog support for the kernel appears.  If I remember correctly, this
was Peter MacDonald, but no mention of that in the sources.

Bruce Evans shows up here quickly.

Bruce was the author of the Minix/386 patches, and had been one of my
sounding boards for my early development, so it was very gratifying to
see him get interested in Linux.  As it turned out, what he was _really_
interested in was the serial driver, and the Linux serial driver was
already in reasonably good shape.

As a result, Bruce went off to work on 386BSD instead (where the serial
driver was truly crappy), but here he worked on some boot loader cleanups.

Bruce was my hero.

Anyway...  More VFS work here: readdir, bmap and ioctl's are now virtual
operations, and the superblock code is properly virtualized.

Other changes:

 - James Wiegand writes initial parallell port printer driver

 - major/minor fault tracking

 - I rewrote big chunks of ptrace.c

Oops.  I had forgotten to change the kernel version number in 0.95 (so
it showed as 0.12).

 - 80x50 console on standard VGA
 - do "memcpy_fromfs()" and "memcpy_tofs()" rather than byte-at-a-time
   to improve performance (inspired by some earlier patches by Keith White)
 - allow select() on many more file descriptors
 - support up to 4 serial ports (and increase buffering size)
 - Branko Lankester helped make extended partitions work and implemented
   DM partition table support

The big deal in the release notes is actually that the root diskette
maintainership had been moved over to Jim Winstead Jr.

This was the first kernel that got released under the GPL (0.12 had a
time-lapse to make sure the people involved accepted the license change:
nobody ever complained).

Because 0.12 had been so successful, this was supposed to be closer to
1.0.  Yeah, right.  1.0 was eventually released almost exactly two years
later..

The big change here is the first signs of a real VFS layer: while the
only available filesystem is still the Minix-compatible one, the code is
factored out, and the Minix-specific stuff is put in its own directory.
You can clearly see how the thing is moving towards having multiple
different filesystems.

The VFS changes also cause cleanups in various drivers, since we end
up having more clear inode operation structure pointer handling.

Superblock handling is still minix-specific..

NOTE! We also have /bin/init finally.  It still falls through to the old
"run shells forever" case if no init can be found, but it's starting to
look a whole more like real UNIX user-land now..

New developers: Ross Biro shows up, and does ptrace.  He will later end
up doing the first-generation networking code.

Other changes:

 - UK and Danish keyboard maps (and the keyboard driver supported
   "Application mode" keys from vt100+)
 - Make sure interrupts clear the 'D'irection flag
 - Floppy driver gets track buffer, which speeds it up immensely.  This
   was done based on patches by Lawrence Foard (entropy@wintermute.wpi.edu)
 - Lots of buffer cache cleanups.
 - support nonblocking pipe file descriptors
 - recursive symlink support
 - sys_swapon() means that we don't have to select the swap device
   at build (or boot) time ("Written 01/25/92 by Simmule Turner, heavily
   changed by Linus")
 - start some generic timer work (ugh, but these first timers were
   _horrible_ hardcoded things)
 - ptrace for debugging
 - console size query support with TIOC[G|S]WINSZ
 - /dev/kmem ("by Damiano")
 - rebooting (with ctrl-alt-del or sys_reboot()).

From the release notes:

              New features of 0.95, in order of appearance
                      (ie in the order you see them)

      Init/login

Yeah, thanks to poe (Peter Orbaeck (sp?)), linux now boots up like a
real unix with a login-prompt.  Login as root (no passwd), and change
your /etc/passwd to your hearts delight (and add other logins in
/etc/inittab etc).

      Bash is even bigger

It's really a bummer to boot up from floppies: bash takes a long time to
load.  Bash is also now so big that I couldn't fit compress and tar onto
the root-floppy: You'll probably want the old rootimage-0.12 just in
order to get tar+compress onto your harddisk.  If anybody has pointers
to a simple shell that is freely distributable, it might be a good idea
to use that for the root-diskette.

Especially with a small buffer-cache, things aren't fun. Don't worry:
linux runs much better on a harddisk.

      Virtual consoles on any (?) hardware.

You can select one of several consoles by pressing the left alt-key and
a function key at the same time. Linux should report the number of
virtual consoles available upon bootup. /dev/tty0 is now "the current"
screen, /dev/tty1 is the main console, and /dev/tty2-8 can exist
depending on your text-mode or card.

The virtual consoles also have some new screen-handling commands: they
confirm even better to vt200 control codes than 0.11. Special graphic
characters etc: you can well use them as terminals to VMS (although
that's a shameful waste of resources), and the PF1-4 keys work somewhat
in the application-key mode.

      Symbolic links.

0.95 now allows symlinks to point to other symlinks etc (the maximum
depth is a rather arbitrary 5 links). 0.12 didn't like more than one
level of indirection.

      Virtual memory.

VM under 0.95 should be better than under 0.12: no more lockups (as far
as I have seen), and you can now swap to the filesystem as well as to a
special partition. There are two programs to handle this: mkswap to set
up a swap-file/partition and swapon to start up swapping.

mkswap needs either a partition or a file that already exists to make a
swap-area. To make a swap-file, do this:

      # dd bs=1024 count=NN if=/dev/hda of=swapfile
      # mkswap swapfile NN

The first command just makes a file that is NN blocks long (initializing
it from /dev/hda, but that could be anything). The second command then
writes the necessary setup-info into the file. To start swapping, write

      # swapon swapfile

NOTE! 'dd' isn't on the rootdisk: you have to install some things onto
the harddisk before you can get up and running.

NOTE2! When linux runs totally out of virtual memory, things slow down
dramatically. It tries to keep on running as long as it can, but at
least it shouldn't lock up any more. ^C should work, although you might
have to wait a while for it..

      Faster floppies

Ok, you don't notice this much when booting up from a floppy: bash has
grown, so it takes longer to load, and the optimizations work mostly
with sequential accesses.  When you start un-taring floppies to get the
programs onto your harddisk, you'll notice that it's much faster now.
That should be about the only use for floppies under a unix: nobody in
their right mind uses floppies as filesystems.

      Better FS-independence

Hopefully you'll never even notice this, but the filesystem has been
partly rewritten to make it less minix-fs-specific. I haven't
implemented all the VFS-patches I got, so it's still not ready, but it's
getting there, slowly.

      And that's it, I think.

Happy hacking.

                      Linus (torvalds@kruuna.helsinki.fi)

This was created from a re-packaged 0.12 tree

Major milestone! Over the christmas break, I implemented paging to disk,
meaning that you could actually use gcc on a 2MB system.  Some poor sod
(Robert Blum) wanted to use Linux on such a system, and couldn't get the
kernel to compile with anything less "bloated" than gcc.

[ Irony alert: this was back when gcc worked fine on a system with just
  4MB.  Gone are those days. _Loong_ gone. ]

The task size was still limited to 63 tasks of at most 64MB each, but
other than that we were actually getting usable.

Together with other improvements and fixes, 0.12 was actually a very
nice kernel.  It was by now clearly more usable than Minix, which caused
us to think that a 1.0 release was imminent.  The next kernel version
was to be named 0.95, which turned out to be less than a stellar idea.

This was also the point where we changed the copyright license.  See the
attached original release notes.

Other changes:

 - Ted Ts'o continued on his rampage, and implemented BSD process
   control (ie ^Z) etc.  This also introduced the process tree code,
   with pointers between parents and children, rather than iterating
   over the whole list of processes.

 - Ted also did SVR4-style "saved uid/gid" handling.

 - use the C preprocessor for assembly files, cleaning up a lot of
   duplicate definitions etc.

 - better boot loader diagnostics

 - boot sequence now can change the size of the text display.  Who the
   hell is d88-man?

 - fix nasty race condition between "truncate" and file IO.

 - add support for shared libraries with the "uselib()" system call.
   This (together with the fact that we could share clean executable
   pages) cut down on memory usage a lot.

 - supplemental group support.  Hey, what can I say? Unix users expected
   them.

 - symbolic link handling.  This was the first real extension to the
   standard Minix disk layout, and was made possible by the fact that I
   had written my own "mkfs" and "fsck".  Before that, we were still on
   crutches, in that a Linux system depended on a Minix installation for
   these fundamental system tools.

 - mkdir()/rmdir() isn't just for root, you know..  (Yes, seriously.
   Old-style UNIX used to limit them to root-only, since they were just
   special sequences of mknod's)

 - Virtual terminals by Peter MacDonald (who was to do the SLS
   distribution).

   Before having X, this was a _big_ deal.  The fact that Linux had
   virtual terminals with a good vt100 emulation actually made Linux
   stand out even among some of the big commercial unixes.  The Linux
   console was just _so_ much more pleasant to use that it isn't even
   funny.

 - first implementation of "select()", virtual terminals, and pty's.

   These too were originally done by Peter MacDonald, based on some
   patches that had been floating around for Minix for a long time (but
   were never accepted into Minix).

   They didn't get accepted into Linux either, but the patches _did_ end
   up inspiring me to re-do the select/pty parts in a way that was more
   palatable to me.

 - restartable system calls

   This was needed for Ted's code to do ^Z

 - Math emulation! The code was a total crock, and didn't bother with
   such unnecessary niceties as getting rounding right (or, to be
   honest, even getting more than about 60 bits right), but let's face
   it: it was enough to get work done.

   My math emulation was eventually to be entirely replaced by a much
   more complete, and much more precise implementation by Bill
   Metzenthen.  But my original stupid implementation actually ended
   living on at least for a while in BSD - I ended up making it
   available to the BSD people who couldn't use Bill's much better
   implementation due to licensing reasons.  I don't know whatever
   eventually happened to it.

 - support alignment check on i486+. Nobody seems to have ever used it,
   though.

Original release notes:

         RELEASE NOTES FOR LINUX v0.12

This is file mostly contains info on changed features of Linux, and
using old versions as a help-reference might be a good idea.

         COPYRIGHT

The Linux copyright will change: I've had a couple of requests to make
it compatible with the GNU copyleft, removing the "you may not
distribute it for money" condition.  I agree.  I propose that the
copyright be changed so that it confirms to GNU - pending approval of
the persons who have helped write code.  I assume this is going to be no
problem for anybody: If you have grievances ("I wrote that code assuming
the copyright would stay the same") mail me.  Otherwise The GNU copyleft
takes effect as of the first of February.  If you do not know the gist
of the GNU copyright - read it.

         INSTALLATION

This is a SHORT install-note. The installation is very similar to 0.11,
so read that (INSTALL-0.11) too. There are a couple of programs you will
need to install linux: something that writes disk images (rawrite.exe or
NU or...) and something that can create harddisk partitions (fdisk under
xenix or older versions of dos, edpart.exe or something like that).

NOTE! Repartitioning your harddisk will destroy all data on it (well,
not exactly, but if you know enough to get back the data you probably
didn't need this warning).  So be careful.

READ THIS THROUGH, THEN READ INSTALL-0.11, AND IF YOU ARE SURE YOU KNOW
WHAT YOU ARE DOING, CONTINUE.  OTHERWISE, PANIC.  OR WRITE ME FOR
EXPLANATIONS.  OR DO ANYTHING BUT INSTALL LINUX - IT'S VERY SIMPLE, BUT
IF YOU DON'T KNOW WHAT YOU ARE DOING YOU'LL PROBABLY BE SORRY.  I'D
RATHER ANSWER A FEW UNNECESSARY MAILS THAN GET MAIL SAYING "YOU KILLED
MY HARDDISK, BASTARD.  I'M GOING TO FIND YOU, AND YOU'LL BE SORRY WHEN I
DO".

1) back up everything you have on your harddisk - linux-0.12 is still in
   beta and might do weird things.  The only thing I guarantee is that
   it has worked fine on /my/ machine - for all I know it might eat your
   harddisk and spit it out in small pieces on any other hardware.

2) Test out the linux boot-disk with the root file system.  If it
   doesn't work, check the hardware requirements, and mail me if you
   still think it should work.  I might not be able to help you, but
   your bug-report would still be appreciated.

   Test that linux can read your harddisk at least partly: run the fdisk
   program on the root-disk, and see if it barfs.  If it tells you about
   any partitions at all, linux can successfully read at least part of
   your harddisk.

3) Make sure that you have a free /primary/ partition.  There can be 4
   primary partitions per drive: newer DOS fdisks seem to be able to
   create only 2 (one primary and one extended).  In that case use some
   other partitioning software: edpart.exe etc.  Linux fdisk currently
   only tells you the partition info - it doesn't write to the disk.

   Remember to check how big your partition was, as that can be used to
   tell which device Linux thinks it is.

4) Boot up linux again, fdisk to make sure you now have the new
   partition, and use mkfs to make a filesystem on one of the partitions
   fdisk reports.  Write "mkfs -c /dev/hdX nnn" where X is the device
   number reported by linux fdisk, and nnn is the size - also reported
   by fdisk.  nnn is the size in /blocks/, ie kilobytes.  You should be
   able to use the size info to determine which partition is represented
   by which device name.

5) Mount the new disk partition: "mount /dev/hdX /user".  Copy over the
   root filesystem to the harddisk, eg like this:

        # for i in bin dev etc usr tmp
        # do
        # cp +recursive /$i /user
        # done

   You caanot use just "cp +recursive / /user", as that will result in a
   loop.

6) Sync the filesystem after you have played around enough, and reboot.

        # sync
        <wait for it to sync>
        ctrl-alt-del

   The folklore says you should do this three times before rebooting:
   once should be enough, but I admit I do it three times anyway :) THIS
   IS IMPORTANT! NEVER EVER FORGET TO SYNC BEFORE KILLING THE MACHINE.

7) Change the bootdisk to understand which partition it should use as a
   root filesystem.  See INSTALL-0.11: it's still the word at offset
   508 into the image. You should be up and running.

That's it. Go back and read the INSTALL-0.11

         New features of 0.12, in order of appearance
         (ie in the order you see them)

        Linux now prints cute dots when loading

WoW. Run, don't walk, to see this :). Seriously, it should hopefully now
load even on machines that never got off the ground before, but
otherwise the loading hasn't changed. Implemented by drew.

        Super-VGA detection for extended alphamun modes

I cannot guarantee it, I didn't write it, but it works great on a ET400
SVGA card.  I'm addicted to the new look with 100x40 character editing,
instead of a cramped 80x25.  This only works on VGA-cards that support
higher text-resolutions, and which are correctly identified. Implemented
by d88-man.

        Job Control.

Ok, everybody used to typing ^Z after they started a long command, and
forgot to put it in the background - now it works on linux too.  Bash
knows the usualy job-control commands: bg, fg, jobs & kill.  I hope
there will be no nasty surprises.  Job control was implemented by
tytso@athena.mit.edu.

        Virtual consoles on EGA/VGA screens.

You can select one of several consoles by pressing the left alt-key and
a function key at the same time. Linux should report the number of
virtual consoles available upon bootup. /dev/tty0 is now "the current"
screen, /dev/tty1 is the main console, and /dev/tty2-8 can exist
depending on your text-mode or card.

NOTE! Scrolling is noticeably much slower with virtual consoles on a
EGA/VGA. The reason is that no longer does linux use all the screen
memory as a long buffer, but crams in several consoles in it. I think
it's worth it.

The virtual consoles also have some new screen-handling commands: they
confirm even better to vt200 control codes than 0.11. Special graphic
characters etc: you can well use them as terminals to VMS (although
that's a shameful waste of resources).

        pty's

Ok. I have to admit that I didn't get the hangup-code working correctly,
but that should be easy to add. The general things are there.

        select

I've never used it, so I cannot say how well it works. My minor testing
seems to indicate that it works ok. vc's, pty's and select were
implemented by pmacdona, although I hacked it heavily.

        387-emulation.

It's not complete, but it works well enough to run those gcc2.0 compiled
programs I tested (few).  None of the "heavy" math-functions are
implemented yet.

        Symbolic links.

Try out a few "ln -s xx yy", and ls -l. Note that I think tar should be
recompiled to know anout them, and probably some other programs too. The
0.12 rootimage-disk has most of the recompiled fileutilities.

        Virtual memory.

In addition to the "mkfs" program, there is now a "mkswap" program on
the root disk.  The syntax is identical: "mkswap -c /dev/hdX nnn", and
again: this writes over the partition, so be careful.  Swapping can then
be enabled by changing the word at offset 506 in the bootimage to the
desired device.  Use the same program as for setting the root file
system (but change the 508 offset to 506 of course).

NOTE! This has been tested by Robert Blum, who has a 2M machine, and it
allows you to run gcc without much memory.  HOWEVER, I had to stop using
it, as my diskspace was eaten up by the beta-gcc-2.0, so I'd like to
hear that it still works: I've been totally unable to make a
swap-partition for even rudimentary testing since about christmastime.
Thus the new changes could possibly just have backfired on the VM, but I
doubt it.

        And that's it, I think.

Happy hacking.

         Linus

This was created from a re-packaged 0.11 tree.

Linux-0.11 has a few rather major improvements, but perhaps most
notably, is the first kernel where some other people start making
real contributions.

 - I fixed the buffer cache code, making it a lot more stable

 - demand-loading from disk. My comment proudly states:

        Once more I can proudly say that linux stood up to being changed: it
        was less than 2 hours work to get demand-loading completely implemented.

   This is a major milestone, since it makes the kernel much more
   powerful than Minix was at the time.  I also share clean pages.

 - we still don't have an /sbin/init, but we now load /etc/rc at bootup,
   and the kernel will loop, spawning shells forever. That makes it easier
   to test things.

 - scaffolding for math emulation introduced.

 - Ted Ts'o shows up as a coder. Ted implements:
        o "#!" escape handling for executables
        o fixes for some file permission handling
        o "sticky" directory bit
        o first "malloc()/free()" implementation.
          (this one is horrible: the free needs the size for good
           performance, which will result in years of "free_s()" pains)
        o adds BSD-style setreuid/gid() handling
        o allows us to specify root device at image build time
        o cleanups of some of the uglier direct %fs-register accesses

 - Galen Hunt shows up as a coder: he's added code to handle different
   video card detection (whereas my original one just handled VGA, we
   now handle CGA, MGA, EGA and VGA)

 - The console can beep now: John T Kohl (who also does the tty KILL
   char handling)

 - we also now have German (Wolfgang Thiel) and French (Marc Corsini)
   keyboard maps.  World Domination!

Btw, if you wonder what the "Urgel" comments are - I was still fairly
Swedish-speaking, and "Urgel" is what I would these days write as "Ugh".

It's a sign of trouble or ugly code.  The floppy driver in particular is
clearly not something I'm very proud of ;).

Likely correct 0.10: these were re-created from the RCS tree that Ted
Ts'o had, no known pristine 0.10 tree (or, sadly, 0.02 and 0.03 trees)
exist any more.

Linux-0.10 was actually a major step.  It was _almost_ able to host
itself, and if I remember correctly, a small patch I posted to the
newsgroup a few days later got the buffer cache handling stable enough
that Linux could now compile itself under itself without running out of
memory due to a memory leak.

Apart from bugfixes, the major update here is the support for
mount/umount.  But you can also tell that others are starting to test
out this thing, since the harddisk geometry is now auto-sensed, and we
support the US keyboard layout in addition to the Finnish one.

(This is also the first actual thing from the outside: the US keyboard
layout tables came from Alfred Leung, although with major editing by me.)

 - add copyright messages ("(C) 1991  Linus Torvalds")

   Nobody else is really doing coding (yet..) but clearly I'm starting
   to be a lot more aware of other people here.

 - split up boot/boot.s into boot/bootsect.s and boot/setup.s
 - autodetect floppy type for booting
 - make root device and boot device configurable

 - support up to 16MB of physical memory (instead of just 8MB ;)

   Whee. We're clearly moving into the "big iron" phase of Linux.

 - move drivers around.  We now have separate subdirectories for
   character device drivers (tty and memory) and block device drivers.

 - initial floppy driver support!

   You can see how the "block layer" interfaces evolved directly from
   moving parts of the original hd.c driver into ll_rw_block.c and
   making them "generic".

 - make file reading do simple read-ahead
 - make file writing avoid reading in blocks that are totally overwritten
 - add support for /dev/port and /dev/null (!!)
 - improve pipe throughput

 - add support for sigaction(), not just old-style signal()

   This also rewrites most of the signal code in C rather than assembly.

 - add "mknod()" and "mount()"/"umount()" system calls, and support
   for traversing over mount-points.

 - add "sessions" and setsid(), so that we get proper SIGHUP's

This is the initial 0.01 kernel as found on various history sites.

Fun facts:

 - kernel/Makefile still calls it the FREAX kernel

 - this was in a more innocent age, when the only copyright notice
   is a single "(C) 1991 Linus Torvalds" in lib/string.h

 - the keyboard driver was still in all assembly language, with a
   hardcoded map for (7-bit) Finnish keyboards. At least I had converted
   the VT100 emulation from assembly to C. Too bad I didn't keep the
   _really_ old code around for historical interest.

 - All the early kernels wanted a special version of gcc to compile: I
   had made extensions to gcc-1.40 to make it use the x86 string
   instructions for things like "memcpy()" using the "-mstring-insns"
   command line option.

 - Also, note that newer versions of gcc (which do have the inline
   intrisics, quite independently of my early -mstring-insns hack) will
   not accept the code: it needs a compiler that outputs old-style a.out
   format, and that accepts some of the strange inline assembly that I
   used.

 - In short: you really need some stone-age tools to actually compile
   this, if you actually want to.  And if you actually want to _run_ it
   too, you need to have some old hardware and most likely edit some of
   the hardcoded numbers too.  The harddisk driver has two different
   hardcoded settings: my harddisk, and Lasu's harddisk.

Statistics:

It's 88 files with about ten thousand lines, written by yours truly
except for the vsprintf routine which was co-written with Lars
Wirzenius.  Lasu wasn't as huge a fan of inline assembly as I was, thus
the comment

        "Wirzenius wrote this portably, Torvalds fucked it up :-)"

I think that comment pretty much sums it up ;)

Original release notes for 0.01 follow:

         Notes for linux release 0.01

         0. Contents of this directory

linux-0.01.tar.Z - sources to the kernel
bash.Z - compressed bash binary if you want to test it
update.Z - compressed update binary
RELNOTES-0.01 - this file

         1. Short intro

This is a free minix-like kernel for i386(+) based AT-machines.  Full
source is included, and this source has been used to produce a running
kernel on two different machines.  Currently there are no kernel
binaries for public viewing, as they have to be recompiled for different
machines.  You need to compile it with gcc (I use 1.40, don't know if
1.37.1 will handle all __asm__-directives), after having changed the
relevant configuration file(s).

As the version number (0.01) suggests this is not a mature product.
Currently only a subset of AT-hardware is supported (hard-disk, screen,
keyboard and serial lines), and some of the system calls are not yet
fully implemented (notably mount/umount aren't even implemented).  See
comments or readme's in the code.

This version is also meant mostly for reading - ie if you are interested
in how the system looks like currently.  It will compile and produce a
working kernel, and though I will help in any way I can to get it
working on your machine (mail me), it isn't really supported.  Changes
are frequent, and the first "production" version will probably differ
wildly from this pre-alpha-release.

Hardware needed for running linux:
        - 386 AT
        - VGA/EGA screen
        - AT-type harddisk controller (IDE is fine)
        - Finnish keyboard (oh, you can use a US keyboard, but not
          without some practise :-)

The Finnish keyboard is hard-wired, and as I don't have a US one I
cannot change it without major problems. See kernel/keyboard.s for
details. If anybody is willing to make an even partial port, I'd be
grateful. Shouldn't be too hard, as it's tabledriven (it's assembler
though, so ...)

Although linux is a complete kernel, and uses no code from minix or
other sources, almost none of the support routines have yet been coded.
Thus you currently need minix to bootstrap the system. It might be
possible to use the free minix demo-disk to make a filesystem and run
linux without having minix, but I don't know...

         2. Copyrights etc

This kernel is (C) 1991 Linus Torvalds, but all or part of it may be
redistributed provided you do the following:

        - Full source must be available (and free), if not with the
          distribution then at least on asking for it.

        - Copyright notices must be intact. (In fact, if you distribute
          only parts of it you may have to add copyrights, as there aren't
          (C)'s in all files.) Small partial excerpts may be copied
          without bothering with copyrights.

        - You may not distibute this for a fee, not even "handling"
          costs.

Mail me at "torvalds@kruuna.helsinki.fi" if you have any questions.

Sadly, a kernel by itself gets you nowhere. To get a working system you
need a shell, compilers, a library etc. These are separate parts and may
be under a stricter (or even looser) copyright. Most of the tools used
with linux are GNU software and are under the GNU copyleft. These tools
aren't in the distribution - ask me (or GNU) for more info.

         3. Short technical overview of the kernel.

The linux kernel has been made under minix, and it was my original idea
to make it binary compatible with minix. That was dropped, as the
differences got bigger, but the system still resembles minix a great
deal. Some of the key points are:

        - Efficient use of the possibilities offered by the 386 chip.
          Minix was written on a 8088, and later ported to other
          machines - linux takes full advantage of the 386 (which is
          nice if you /have/ a 386, but makes porting very difficult)

        - No message passing, this is a more traditional approach to
          unix. System calls are just that - calls. This might or might
          not be faster, but it does mean we can dispense with some of
          the problems with messages (message queues etc). Of course, we
          also miss the nice features :-p.

        - Multithreaded FS - a direct consequence of not using messages.
          This makes the filesystem a bit (a lot) more complicated, but
          much nicer. Coupled with a better scheduler, this means that
          you can actually run several processes concurrently without
          the performance hit induced by minix.

        - Minimal task switching. This too is a consequence of not using
          messages. We task switch only when we really want to switch
          tasks - unlike minix which task-switches whatever you do. This
          means we can more easily implement 387 support (indeed this is
          already mostly implemented)

        - Interrupts aren't hidden. Some people (among them Tanenbaum)
          think interrupts are ugly and should be hidden. Not so IMHO.
          Due to practical reasons interrupts must be mainly handled by
          machine code, which is a pity, but they are a part of the code
          like everything else. Especially device drivers are mostly
          interrupt routines - see kernel/hd.c etc.

        - There is no distinction between kernel/fs/mm, and they are all
          linked into the same heap of code. This has it's good sides as
          well as bad. The code isn't as modular as the minix code, but
          on the other hand some things are simpler. The different parts
          of the kernel are under different sub-directories in the
          source tree, but when running everything happens in the same
          data/code space.

The guiding line when implementing linux was: get it working fast. I
wanted the kernel simple, yet powerful enough to run most unix software.
The file system I couldn't do much about - it needed to be minix
compatible for practical reasons, and the minix filesystem was simple
enough as it was. The kernel and mm could be simplified, though:

        - Just one data structure for tasks. "Real" unices have task
          information in several places, I wanted everything in one
          place.

        - A very simple memory management algorithm, using both the
          paging and segmentation capabilities of the i386. Currently
          MM is just two files - memory.c and page.s, just a couple of
          hundreds of lines of code.

These decisions seem to have worked out well - bugs were easy to spot,
and things work.

         4. The "kernel proper"

All the routines handling tasks are in the subdirectory "kernel". These
include things like 'fork' and 'exit' as well as scheduling and minor
system calls like 'getpid' etc. Here are also the handlers for most
exceptions and traps (not page faults, they are in mm), and all
low-level device drivers (get_hd_block, tty_write etc). Currently all
faults lead to a exit with error code 11 (Segmentation fault), and the
system seems to be relatively stable ("crashme" hasn't - yet).

         5. Memory management

This is the simplest of all parts, and should need only little changes.
It contains entry-points for some things that the rest of the kernel
needs, but mostly copes on it's own, handling page faults as they
happen. Indeed, the rest of the kernel usually doesn't actively allocate
pages, and just writes into user space, letting mm handle any possible
'page-not-present' errors.

Memory is dealt with in two completely different ways - by paging and
segmentation.  First the 386 VM-space (4GB) is divided into a number of
segments (currently 64 segments of 64Mb each), the first of which is the
kernel memory segment, with the complete physical memory identity-mapped
into it.  All kernel functions live within this area.

Tasks are then given one segment each, to use as they wish. The paging
mechanism sees to filling the segment with the appropriate pages,
keeping track of any duplicate copies (created at a 'fork'), and making
copies on any write. The rest of the system doesn't need to know about
all this.

         6. The file system

As already mentioned, the linux FS is the same as in minix. This makes
crosscompiling from minix easy, and means you can mount a linux
partition from minix (or the other way around as soon as I implement
mount :-). This is only on the logical level though - the actual
routines are very different.

        NOTE! Minix-1.6.16 seems to have a new FS, with minor
        modifications to the 1.5.10 I've been using. Linux
        won't understand the new system.

The main difference is in the fact that minix has a single-threaded
file-system and linux hasn't. Implementing a single-threaded FS is much
easier as you don't need to worry about other processes allocating
buffer blocks etc while you do something else. It also means that you
lose some of the multiprocessing so important to unix.

There are a number of problems (deadlocks/raceconditions) that the linux
kernel needed to address due to multi-threading.  One way to inhibit
race-conditions is to lock everything you need, but as this can lead to
unnecessary blocking I decided never to lock any data structures (unless
actually reading or writing to a physical device).  This has the nice
property that dead-locks cannot happen.

Sadly it has the not so nice property that race-conditions can happen
almost everywhere.  These are handled by double-checking allocations etc
(see fs/buffer.c and fs/inode.c).  Not letting the kernel schedule a
task while it is in supervisor mode (standard unix practise), means that
all kernel/fs/mm actions are atomic (not counting interrupts, and we are
careful when writing those) if you don't call 'sleep', so that is one of
the things we can count on.

         7. Apologies :-)

This isn't yet the "mother of all operating systems", and anyone who
hoped for that will have to wait for the first real release (1.0), and
even then you might not want to change from minix.  This is a source
release for those that are interested in seeing what linux looks like,
and it's not really supported yet.  Anyone with questions or suggestions
(even bug-reports if you decide to get it working on your system) is
encouraged to mail me.

         8. Getting it working

Most hardware dependancies will have to be compiled into the system, and
there a number of defines in the file "include/linux/config.h" that you
have to change to get a personalized kernel.  Also you must uncomment
the right "equ" in the file boot/boot.s, telling the bootup-routine what
kind of device your A-floppy is.  After that a simple "make" should make
the file "Image", which you can copy to a floppy (cp Image /dev/PS0 is
what I use with a 1.44Mb floppy).  That's it.

Without any programs to run, though, the kernel cannot do anything. You
should find binaries for 'update' and 'bash' at the same place you found
this, which will have to be put into the '/bin' directory on the
specified root-device (specified in config.h). Bash must be found under
the name '/bin/sh', as that's what the kernel currently executes. Happy
hacking.

         Linus Torvalds "torvalds@kruuna.helsinki.fi"
         Petersgatan 2 A 2
         00140 Helsingfors 14
         FINLAND