Linux History 101 :)
Ragnar Hojland Espinosa
Here's one of the little jewels I have floating in /doc/
Subject: Writing an OS - questions !!
Date: 5 May 92 01:57:05 GMT
Reply-To: na...@td2cad.intel.com (V. Narayanan)
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.
1) How would you typically debug the kernel during the development phase?
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?
3) Would new linkers and loaders have to be written before you get a basic
kernel running?
4) Was Linux developed in a DOS environment? Maybe Linus could shed some light
on this subject.
Thanks in anticipation.
N. Venkat
From: baz...@mrcnext.cso.uiuc.edu (Jawaid Bazyar)
Newsgroups: comp.os.linux
Subject: Re: Writing an OS - questions !!
Date: 5 May 92 03:33:10 GMT
Organization: University of Illinois at Urbana
na...@td2cad.intel.com (V. Narayanan) writes:
Having just written a Multitasking OS, I couldn't resist...
>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.
>1) How would you typically debug the kernel during the development phase?
On my machine (Apple IIgs), we have a machine-language debugger which
has a number of nifty features, the most important here being that it
'turns-on' whenever certain reserved software traps are activated. You
can intersperse these in your code to trace certain locations.
And, there's always the infamous "printf" method, printing out every
value you deem relevant to the problem.
You probably won't be able to use existing source-level debuggers (see
below), but this is just conjecture on my part and indeed depends on how
you initially implement the system.
>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, and in fact many classes in OS design are taught with this principle.
"Operating System Design" by Douglas Comer implements a Unix-like OS
called XINU. There is source code publically available for a version
of XINU which runs under UNIX systems. This system works by basically
implementing threads (multiple processes inside one real Unix process).
Your mention of the new OS accessing privileged registers is a good question,
and as far as I know there's no good answer except one: you have to get
the basic multitasking and low-level OS features working by sweat alone.
Usually, you have to boot into your new OS, instead of running it from
your development system. This means that you have a really tedious
test, reboot, compile, reboot, test cycle.
>3) Would new linkers and loaders have to be written before you get a basic
> kernel running?
No, the standard technique is to use a cross compiler of some sort.
If the OS you're writing is for the same processor your development system
is on, then most of the problem is solved. All you need to do is avoid
using any library routines that use the development system's OS. Now,
when you get to the point where you want to start using the C compiler
under your new system, you have a bit of a problem (unless your new OS
can run other OS's software, kinda like OS2->Windows, Windows->DOS, etc).
As far as loaders, you probably would want to for later user programming,
but most OS's are written to be loaded into a pre-defined area of physical
memory, and thus you won't need a loader to boot your system. In any
event, loaders are in general fairly simple, and you could probably
emulate existing ones (so as to be able to use existing compilers, etc).
Writing an OS is probably one of the most satisfying things I've done;
I wouldn't recommend it for the faint of heart, however. :)
--
Jawaid Bazyar | Ask me about the GNO Multitasking Environment
Procyon, Inc. | for the Apple IIgs! (314) 334-7078
baz...@cs.uiuc.edu | 1005 N. Kingshighway, Suite 309
--Apple II Forever!-- | Cape Girardeau, MO 63701
From: torv...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Writing an OS - questions !!
Date: 5 May 92 07:58:17 GMT
In article <10...@inews.intel.com> na...@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: sin...@scintilla.capitola.ca.us (Darren Senn)
Newsgroups: comp.os.linux
Subject: Re: Writing an OS - questions !!
Date: 5 May 92 18:29:42 GMT
I started an OS called Syrinx in Summer of 1990. It started off being
286 specific (that was what I had), and is now 486 specifc (thank god
for upgrades)! Feeling an overwhelming desire to continue this thread,
here's my 2 cents.
Syrinx was largely inspired by BSD 4.3 and some little hardware experiments
that I did in my Computer Engineering studies.
I started off from scratch, by writing some utilities under Borland C that
allowed me to format a partition with the Syrinx filesystem, and then copy
files to the filesystem, etc.
Once I did that, I pulled up TASM, and started with my bootsector. I wrote
a little bootsector that could multi-boot between DOS and Syrinx. If you
hit return, it would boot Syrinx, but if you typed "DOS", it would go to
the first primary DOS partition and boot that. In order to boot Syrinx,
I loaded a file called "/init" and executed it.
The first version of the boot sector took about a month to write and debug,
(I HATE DEBUGGING BOOT CODE!) and had the location of /init hardwired into
it. The second version actually searched the filesystem for /init by looking
through directories and the inodes, and took another two months.
Linus mentioned his "die loops". I did something very similar to that, though
my die loops started off by creating an exploding window in the middle of the
screen (ok, so I was bored :) ), and putting the values of all the registers
into that window, then it went into a pretty solid loop:
@@die: sti ; Disable interrupts
hlt ; Halt the computer
jmp @@die ; If I get out of the halt, repeat!
So this thing pretty solidly stopped the microprocessor, and I didn't have
any problems with reboots clearing the screen. Very helpful.
I had to deal with the debug/compile/write/reboot/... loop that Jawaid
Bazyar mentioned. It was slow, but it worked...
There were two big things that slowed me down:
a) My filesystem was fully formed from the start, and
b) I switched to protected mode through the BIOS.
I didn't (at that time) know how protected-mode friendly BIOS was, so I
went ahead and used the BIOS function call to switch into protected mode.
That gave me the bonus of getting a descriptor for the BIOS data segment
in my GDT for free. Very helpful. Unfortunately, I really had to go
through loops to keep the BIOS from using my hardware interrupts. Very
ugly.
I never did get as far as Linux has come, so when I found Linux last month,
I jumped in with both feet. Some of my Syrinx stuff is better than Linux's,
but most of Linux is far more advanced than Syrinx ever got.
In general, I think Linus' tactic of getting a bare system up first is a
better bet than trying to make everything fully-formed as you go. I
never did get a C compiler, but I did write an assembler that worked under
Syrinx (I called it Sinas).
One thing that helped my Syrinx development was DOS EXE compatibility. I
checked the header of any files that you tried to execute, and if it was
a DOS EXE header, then I ran it in V86 mode. I could get a number of things
to run, but anything that tried to switch to protected mode would die in
a rather horrible way, so there were a lot of things I couldn't use. I
also didn't support EMS or XMS or DPMI, so those programs were all out.
Basically, what it came down to was that I couldn't run any commercial
programs. :(
Syrinx has now been shoved way back on the burner, however, and I've
gone whole-hog into Linux.
One of the first things I did when I got Linux was to look at the kernel
code (the equivalent to my /init). I was rather surprised to see that
Linus switched to protected mode all on his own, without going through
the BIOS. I also like his little comment in the sources:
! This is how real programmers do it
or something to that effect. :)
From: wo...@neuron.et.tudelft.nl (Rogier Wolff)
Newsgroups: comp.os.linux
Subject: Re: Writing an OS - questions !!
Date: 6 May 92 09:51:12 GMT
rh...@cs.uq.oz.au (Rhys Weatherley) writes:
>Thanks for posting that Linus - it's very good to read how it all began. I
>hope that the FTP site administrators save away your message as a piece of
>Linux folklore. I especially liked the bit about you being proud of your
>two AAAA... and BBBB... processes. :-)
>Cheers,
I once "ported" XINU to a PDP 11. (It was written on one, but you don't
get some, necessary software with the book, and you'd need a VAX that we
didn't have to run it. Also some PDP11s have hardware MUL and DIV while
others don't)
Anyway we ran the same test: One process printing "process A" and the
other "process B". This resulted in the following output:
process A
process A
process A
prpocess A
process A
process A
procress A
process A
And we where thinking of bugs in the tty code, when it struck that the
output buffer was filling, and process B was mad runnable untill it
printed exactly one character. This blocked process B, and would wait
until the buffer cleared. Next process A would be made runnable again,
and be allowed to fill most of the buffer again.....
Yes, we where also proud that this worked!
Roger
--
If the opposite of "pro" is "con", what is the opposite of "progress"?
(stolen from kad...@iitvax.iit.edu)
EMail: wo...@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371
From: t...@telematics.com (Ted Goldblatt)
Newsgroups: comp.os.linux
Subject: Re: Writing an OS - questions !!
Date: 6 May 92 22:46:52 GMT
In article <10...@inews.intel.com> na...@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.
>
>1) How would you typically debug the kernel during the development phase?
I can only speak from the point of view of building a system on non-PC
type hardware. I don't know how relevent this is to someone who wishes
to build a system on a PC type platform as it normally exists, especially
if it is for hobby type use as opposed to "for real" (i.e., if you don't
have _lots_ of time and _lots_ of money to spend).
The first step was (would be) to build (if not already present) a
"debug monitor". (Actually, I once worked on a system without this,
but that was on a machine that had a "real" front panel :-), so it's
too far in the past to think about.)
The debug monitor is actually a collection of software, normally
resident in a ROM/EPROM. On the system I currently work on, this
includes automatic hardware health checks, stand-alone I/O support
for the console, disk, and network (the equivalent of a PC's BIOS,
I believe), assorted initialization functions, and (most important
for this discussion) a command interpreter.
The command interpreter's commands allow such things as examining and
modifying memory and registers, planting breakpoints, and loading and
running programs (e.g., off of disk). Using the breakpoint capability,
breakpoints can be planted in the O/S (which is just another program
to the monitor), and the examine and modify capabilities can be used
when a breakpoint is hit to see what is going on.
Now (you ask), how do you debug the debug monitor? For that, we use
hardware debugging facilities, principally emulators and logic
analyzers. An emulator gives you capabilities similar to those of
the debug monitor, but totally external to the system (they don't
depend on any of the system's facilities to work). It generally
plugs into the microprocessor socket, replacing the micro.
The tool I use much more often is a logic analyzer, which also plugs
into the micro socket. However, rather than giving you monitor-like
capabilities, the analyzer can just look at what is happening on the
chip's pins. It provides you a way to capture the micro's
interactions with the "outside world" (mostly memory). Its benefits
are that (most) logic analyzers have very elaborate facilities for
conditionally choosing _what_ is captured (triggering and selection)
as well as the ability to watch other things in parallel (bus
activity, I/O chips, etc.) with cross correlation and time stamping.
These gadgets are _very_ useful, especially for watching interactions
of multiprocessors and other concurrent activities. Even with a good
debug monitor available on our system, I still make heavy use of a
logic analyzer for O/S debugging. The major downsides are that they
tend to be low-level debugging tools (assembly level, maybe with
symbols, sometimes with limited support for C), and they are expensive
(the one I generally use is a good one, and supports 3 processors and
a 2 channel digital scope simultaneously, but it cost $45K).
>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?
This is very dependent on the underlying H/W (it assumes all necessary
requests would be trapped cleanly, and that the machine model captures
sufficient information). In many cases, for this to work, the
underlying O/S would have to be changed to emulate the required
facilities transparently. This may or may not be possible. Also,
timing would be completely different, so this approach would have
limited benefit in finding timing related problems, and might not work
at all if the system in question was real-time or had timing
constraints of its own. However, this idea _is_ the basis for virtual
machine systems (e.g., VM/370), and (if it can be employed) is very
useful. Note that true virtual machine operation (as opposed to S/W
emulation) cannot be done on all processors. The Moto 68010, 68020,
and 68030 do support this, but the 68040 _does not_. I don't know the
Intel line well enough to tell, but I have heard that the chips can
virtualize lower members of the family but not themselves.
>3) Would new linkers and loaders have to be written before you get a basic
> kernel running?
Certainly not before. Whether they were needed before the system was
useful depends in part on what the system's intended facilities are
and what object module and load module formats were chosen. Linkers
need not be O/S dependent (though they normally are at least
somewhat), and loaders need not be complex (especially in a system
that uses demand paged loading - of course in this case, you just
pushed the work into your virtual memory system :-)).
>4) Was Linux developed in a DOS environment? Maybe Linus could shed some light
> on this subject.
Left for Linus :-)
--
Ted Goldblatt t...@telematics.com (305) 351-4367
Telematics Intl., Inc. Ft. Lauderdale, FL
From: torv...@klaava.Helsinki.FI (Linus Benedict Torvalds)
Subject: Re: To Linus, Lions book?
Date: 3 Jul 92 11:35:06 GMT
In article <1992Jul3.0...@athena.mit.edu> J.Ja...@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
--
____/| Ragnar Hojland (rag...@lightside.ddns.org) Fingerprint 94C4B
\ o.O| _______________________________________________ 2F0D27DE025BE2302C
=(_)= | 7 Diciembre, manifestacion contra Telefonica! | 104B78C56 B72F0822
U | No faltes!! http://www.internautas.org/7D/) | hkp://keys.pgp.com
-----------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Jim Nance
>
> Here's one of the little jewels I have floating in /doc/
>
> Subject: Writing an OS - questions !!
> Date: 5 May 92 01:57:05 GMT
> Reply-To: na...@td2cad.intel.com (V. Narayanan)
The really scarry thing is that I remember these from when they were
originally posted. I cant believe its been over 6 years.
Jim
--
----------------------------------------------------------------------------
Jim Nance Avant! Corporation
(919) 941-6655 Do you have sweet iced tea? jim_...@avanticorp.com
No, but there's sugar on the table.
Paul Wouters
Benedict? :)
> 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.
I feel much better now. I felt bad for doing a filesystem check with
mke2fs (twice!)
Paul
Simon Kenyon
I'm going to start to pull together anything and everything that I can find about
the history of the Linux OS. Could everybody please send me any/all of the
following:
- original and significant email/new messages
- timings of releases
- biographies of contributors to the kernel, utilities
- pointers to web pages containing information
- stories/photographs of amusing and/or significant occasions
I'll put this together on a web site and try to keep it up to date. This OS is
important to a lot of people and we should keep a record of what/why/how happened
and when.
Any and all help appreciated.
--
simon
Riley Williams
> The History of the Linux Operating System
> I'm going to start to pull together anything and everything that I
> can find about the history of the Linux OS.
===8<=== CUT ===>8===
What I'd like to see is some of the early releases of Linux, just out
of curiosity. Problem is, they all appear to be long since filed in
the old circular file...
Best wishes from Riley.
Simon Kenyon
> What I'd like to see is some of the early releases of Linux, just out
> of curiosity. Problem is, they all appear to be long since filed in
> the old circular file...
i'll see what i can dig up
anyone able to help?
--
simon
Riley Williams
>> What I'd like to see is some of the early releases of Linux, just
>> out of curiosity. Problem is, they all appear to be long since
>> filed in the old circular file...
> i'll see what i can dig up - anyone able to help?
I've so far had ELEVEN private emails pointing out that the majority
of the historic kernels can be found in:
ftp://ftp.kernel.org/pub/linux/kernel/historic
I've just had a look at the SunSite-UK mirror thereof, and note the
following kernel tarballs thereon, in various directories:
0.01
0.10
0.11
0.12
0.95
0.95a
0.96a (plus patches 2, 3 and 4)
0.96b (plus patches 1 and 2)
0.96c (plus patches 1 and 2)
0.96c+
0.97
0.99 (plus patches 1 through 9 and 11 through 13)
0.99.1 through 0.99.7
0.99.7A
0.99.8 through 0.99.11
0.99.12 (plus linux-0.99.12.small-patch)
0.99.13
0.99.15
1.0 (plus patches 1 through 9)
1.1.13
1.1.23 1.1.29
1.1.33 1.1.35
1.1.45
1.1.52 1.1.59
1.1.63 1.1.64 1.1.67
1.1.70 1.1.71 1.1.73 1.1.74 1.1.75 1.1.76
1.1.78 through 1.1.95
1.2.0 through 1.2.13
1.3.0
1.3.2 through 1.3.100
pre2.0.1 through pre2.0.14
2.0
2.0.1 through 2.0.36
2.1.0 through 2.1.24
2.1.27 through 2.1.129
Judging by that list, there's still quite a few missing versions, so
if anybody has copies of the remaining versions, I'd certainly be
interested therein...
For comparison, I've extracted the entries for a few of the major
releases thereof, dates taken from the archive contents:
17 Sep 1991 63,362 linux-0.01.tar.bz2
13 Dec 1992 850,885 linux-0.99.tar.Z <=>
13 Mar 1994 1,016,601 linux-1.0.tar.bz2
23 May 1994 1,083,514 linux-1.1.13.tar.bz2
2 Mar 1995 1,849,466 linux-1.1.95.tar.bz2
9 Jun 1996 4,718,270 linux-2.0.tar.bz2
30 Sep 1996 4,897,927 linux-2.1.0.tar.bz2
15 Nov 1998 5,913,353 linux-2.0.36.tar.bz2
19 Nov 1998 10,064,120 linux-2.1.129.tar.bz2
That's an interesting growth in file size over the last 7.2 years, and
really shows how something can change...
Best wishes from Riley.
Gregory Maxwell
> > From: torv...@klaava.Helsinki.FI (Linus Benedict Torvalds)
>
> Benedict? :)
>
> > 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.
>
> I feel much better now. I felt bad for doing a filesystem check with
> mke2fs (twice!)
For a long time my mke2fs and mkswap were suid nobody after mkswaping my
root fs. At least you can recover from a mkswap on ext2.
Andrea Arcangeli
>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 :)
I feel much better now too :). I always asked myself how Linus could
have handled the load of writing Linux and studying at the same time...
Gregory Maxwell
the historic dir on ftp.kernel.org I assume has them. If not I've got a
.12 root/boot someplace..:)
On Sun, 22 Nov 1998, Riley Williams wrote:
> Hi Simon.
>
> > The History of the Linux Operating System
>
> > I'm going to start to pull together anything and everything that I
> > can find about the history of the Linux OS.
>
> ===8<=== CUT ===>8===
>
> What I'd like to see is some of the early releases of Linux, just out
> of curiosity. Problem is, they all appear to be long since filed in
> the old circular file...
>
> Best wishes from Riley.
H. Peter Anvin
By author: Riley Williams <r...@bigfoot.com>
In newsgroup: linux.dev.kernel
>
> I've so far had ELEVEN private emails pointing out that the majority
> of the historic kernels can be found in:
>
> ftp://ftp.kernel.org/pub/linux/kernel/historic
>
> I've just had a look at the SunSite-UK mirror thereof, and note the
> following kernel tarballs thereon, in various directories:
>
> if anybody has copies of the remaining versions, I'd certainly be
> interested therein...
>
We are indeed missing a number of historic kernels (before 1.0). If
anyone has them, I would appreciate a copy.
-hpa
--
PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
See http://www.zytor.com/~hpa/ for web page and full PGP public key
I am Bahá'í -- ask me about it or see http://www.bahai.org/
"To love another person is to see the face of God." -- Les Misérables
Pavel Janik ml.
Date: Sun, 22 Nov 1998 13:45:47 +0000 (GMT)
Hi,
> What I'd like to see is some of the early releases of Linux, just out
> of curiosity.
:-) You can see LSD on htpp://lsd.linux.cz - I hope you'll be
surprised...
--
Pavel Janik ml.
Pavel...@inet.cz
aar...@vitelus.com
http://www.dina.kvl.dk/%7Eabraham/Linus_vs_Tanenbaum.html
On Sun, 22 Nov 1998, Simon Kenyon wrote:
> On 22-Nov-98 Riley Williams wrote:
> > What I'd like to see is some of the early releases of Linux, just out
> > of curiosity. Problem is, they all appear to be long since filed in
> > the old circular file...
>
> i'll see what i can dig up
> anyone able to help?
> --
> simon
>
Guest section DW
We are indeed missing a number of historic kernels (before 1.0). If
anyone has them, I would appreciate a copy.
What versions do you have in mind?
I have a
-rw-r--r-- 1 aeb aeb 444413 Aug 17 1992 linux97.taz
(on a xiafs filesystem - good that that is still supported under 2.0 :-)
Checking the contents I find that it is the same as linux-0.97.tar.Z
dated Sep 27, 1992. So, the file dates in the
ftp://ftp.kernel.org/pub/linux/kernel/Historic/
directories are probably not the original ones.
I have 0.99/pl15[a-j], 0.99/pl14[a-z] but from the earlier 0.99pl*
only a few edited by me - no clean copies.
[Am certainly interested in missing fragments.]
But old kernels are fairly well documented.
The remaining fragments of software are more difficult to find.
The oldest binary for libc that I can find is libc2.2.2.
But I have source only since libc-4.4.1.
Any older sources are welcome.
Andries
P.S. I suspect that CDROM manufacturers like Yggdrasil or TransAmerican
or so must have snapshots of fairly old systems - but again perhaps
only binaries?
Johnny Tevessen
> I've just had a look at the SunSite-UK mirror thereof, and note the
> following kernel tarballs thereon, in various directories:
Is there a note about which is the oldest kernel version one can
actually compile using recent tools (gcc-2.7.2+, binutils-2.8+,
make-3.7x+)?
> 1.2.0 through 1.2.13
I once had 1.2.13pl9 and pl10 for m68k Amigas. I'm not sure whether
these pl releases were official kernels which had *then* m68k patches
applied to them.
I also once had at least one kernel which had PATCHLEVEL= or
SUBLEVEL= set to "99" in the Makefile. Not sure which version
this actually was (it was >=1.2.x), but I remember that the
numbers in its tar filename mentioned a slightly different
version. Maybe a lookup in the kernel archive could help.
Do you plan to archive non-x86 kernels, too? Sometimes their
evolution was interesting, too (especially the older/first
ports).
ciao,
johnny
--
Trust no-one.
Simon Kenyon
> Do you plan to archive non-x86 kernels, too? Sometimes their
> evolution was interesting, too (especially the older/first
> ports).
as this contains a question - i'll answer
please don't expect answers to mail messages that contain information
although it is very well appreciated, there are too many to reply individually - i
hope people understand
anyway, i will archive all the kernels that i can find and make them available for
download - but not instantly - this will take some time or organise and it is
incidental to my task of writing a history of the evolution of Linux
looks like i'll have to work out how to get DVD's mastered
i was hoping to put stuff on CD - but a rough
"back of fag^h^h^hcigarette packet"
(another term i cannot use any more because itis not PC)
calculation shows me that a CD or three will not be enough
--
simon
Riley Williams
>> I've just had a look at the SunSite-UK mirror thereof, and note
>> the following kernel tarballs thereon, in various directories:
> Is there a note about which is the oldest kernel version one can
> actually compile using recent tools (gcc-2.7.2+, binutils-2.8+,
> make-3.7x+)?
I havenae had a look, sorry...
>> 1.2.0 through 1.2.13
> I once had 1.2.13pl9 and pl10 for m68k Amigas. I'm not sure
> whether these pl releases were official kernels which had *then*
> m68k patches applied to them.
> I also once had at least one kernel which had PATCHLEVEL= or
> SUBLEVEL= set to "99" in the Makefile. Not sure which version
> this actually was (it was >=1.2.x), but I remember that the
> numbers in its tar filename mentioned a slightly different
> version. Maybe a lookup in the kernel archive could help.
Nodz...
> Do you plan to archive non-x86 kernels, too? Sometimes their
> evolution was interesting, too (especially the older/first
> ports).
I wasnae actually planning on archiving anything yet, as I just don't
have any spare disk space. However, something along the lines of a CVS
archive with all the kernel sources and official patches in order
might not be a bad idea...
Best wishes from Riley.
Riley Williams
>> Do you plan to archive non-x86 kernels, too? Sometimes their
>> evolution was interesting, too (especially the older/first ports).
> as this contains a question - i'll answer - please don't expect
> answers to mail messages that contain information although it is
> very well appreciated, there are too many to reply individually - i
> hope people understand
I understand that...
> anyway, i will archive all the kernels that i can find and make
> them available for download - but not instantly - this will take
> some time or organise and it is incidental to my task of writing a
> history of the evolution of Linux
I've been looking into setting up a CVS tree that will contain the
full kernel source history...
> looks like i'll have to work out how to get DVD's mastered i was
> hoping to put stuff on CD - but a rough "back of fag^h^h^hcigarette
> packet" (another term i cannot use any more because itis not PC)
> calculation shows me that a CD or three will not be enough
Put them in a CVS archive, and you replace "sum of kernel source
archive sizes" with "sum of upgrade patch file sizes", and thus
massively reduce the size of the result...
I would suspect the result will fit on a ZipDisk, never mind a CD, but
I'll not know for sure until I get it set up...
Are there any CVS experts out there?
Simon Kenyon
> I've been looking into setting up a CVS tree that will contain the
> full kernel source history...
> Put them in a CVS archive, and you replace "sum of kernel source
> archive sizes" with "sum of upgrade patch file sizes", and thus
> massively reduce the size of the result...
> I would suspect the result will fit on a ZipDisk, never mind a CD, but
> I'll not know for sure until I get it set up...
> Are there any CVS experts out there?
now we're getting somewhere
trouble is - as the puzzle unfolds, what do you do about the situation where an
intermediate release turns up
say we have 1.1.1, 1.1.3, 1.1.4
put them in cvs and all of a sudden 1.1.2 appears from some kindly soul
can cvs/rcs/sccs (you choose) handle this?
--
simon
Jim Gettys
It is worth digging up the oldest Linux versions you can while it is still
possible.
I have some old X stuff around (somewhere around X1 or X2), but regret
having not been more systematic myself. (would be painful to get up these
days; the display hardware is dramatically different and some of the early
X software was written in CLU; so early days of the X Window System are
unlikely to ever re-emerge from the twilight of history.)
There are a group of people on the net who are preserving old systems
and software.
For example, no one will ever see UNIX before version 5, even though emulators
exist for the hardware they ran on: Dennis Ritchie and others have been
unable to find either a bootable disk image or sources to earlier versions.
V5 and later versions can be played with today under emulators. (Would
be easy to get the PDP-11 simulator running under Linux; I've suggested to
Bob Supnik that it would be a good thing to do).
- Jim
Geert Uytterhoeven
> > anyway, i will archive all the kernels that i can find and make
> > them available for download - but not instantly - this will take
> > some time or organise and it is incidental to my task of writing a
> > history of the evolution of Linux
>
> full kernel source history...
That's indeed a good idea.
> > looks like i'll have to work out how to get DVD's mastered i was
> > hoping to put stuff on CD - but a rough "back of fag^h^h^hcigarette
> > packet" (another term i cannot use any more because itis not PC)
> > calculation shows me that a CD or three will not be enough
>
> Put them in a CVS archive, and you replace "sum of kernel source
> archive sizes" with "sum of upgrade patch file sizes", and thus
> massively reduce the size of the result...
>
> I would suspect the result will fit on a ZipDisk, never mind a CD, but
> I'll not know for sure until I get it set up...
I wouldn't count on the Zip. Just did a `du' on my CVS Linux kernel archive
(containing branches for Linus' 2.1.x releases, Jes' Linux/m68k 2.1.x releases,
lots of vger copies, and my personal tree, all since December 1997 only) and I
saw 157832 KB.
BTW, will you guys do the m68k releases too?
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uyt...@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
Simon Kenyon
> For example, no one will ever see UNIX before version 5, even though emulators
> exist for the hardware they ran on: Dennis Ritchie and others have been
> unable to find either a bootable disk image or sources to earlier versions.
> V5 and later versions can be played with today under emulators. (Would
> be easy to get the PDP-11 simulator running under Linux; I've suggested to
> Bob Supnik that it would be a good thing to do).
remember the paper in software p & e where some chap emulated the 11 using a dg
nova and fortran
ran v7 (or was it v6) a 3% of the speed of an 11/34
i remember asking dennis about it
his opinion was that it was quite a feat of engineering
i had a friend who did something similar
he had a 32v tape and was running vms
so he loaded the tape onto disk and wrote code to unpick the blocks and grabbed
the binaries for as and cc and would load them high and trap "change mode to
kernel" (i forget what the instruction is/was) and emulated the unix system calls
with bits for fortran
got the assembler, c compiler and sundry other stuff running
this was in 1979
--
simon
Geert Uytterhoeven
> On 23-Nov-98 Riley Williams wrote:
> > full kernel source history...
> > archive sizes" with "sum of upgrade patch file sizes", and thus
> > massively reduce the size of the result...
> > I would suspect the result will fit on a ZipDisk, never mind a CD, but
> > I'll not know for sure until I get it set up...
>
> now we're getting somewhere
> trouble is - as the puzzle unfolds, what do you do about the situation where an
> intermediate release turns up
>
> say we have 1.1.1, 1.1.3, 1.1.4
> put them in cvs and all of a sudden 1.1.2 appears from some kindly soul
> can cvs/rcs/sccs (you choose) handle this?
That's why we have tags. After checking in 2.1.129, you say
cvs tag linus-2-1-129
After that you can say
cvs co linus-2-1-129
to check out 2.1.129.
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uyt...@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
Simon Kenyon
>> say we have 1.1.1, 1.1.3, 1.1.4
>> put them in cvs and all of a sudden 1.1.2 appears from some kindly soul
>> can cvs/rcs/sccs (you choose) handle this?
>
> That's why we have tags. After checking in 2.1.129, you say
>
> cvs tag linus-2-1-129
>
> After that you can say
>
> cvs co linus-2-1-129
>
> to check out 2.1.129.
i obviously didn't explain myself :-)
i have 1.1.1
i put it in rcs
THEN i get 1.1.47
so i put that in rcs
NOW i get 1.1.x where 1 < x < 47
how do i insert that inbetween 1.1.1 and 1.1.47?
not something you would normally do with sccs/rcs
but then again - writing detective stories was not what rcs was designed for
knowing how rcs stores the deltas i really can't see how it would doo it
can bitmover help?
--
simon
Geert Uytterhoeven
> >> say we have 1.1.1, 1.1.3, 1.1.4
> >> put them in cvs and all of a sudden 1.1.2 appears from some kindly soul
> >> can cvs/rcs/sccs (you choose) handle this?
> >
> > That's why we have tags. After checking in 2.1.129, you say
> >
> > cvs tag linus-2-1-129
> >
> > After that you can say
> >
> > cvs co linus-2-1-129
> >
> > to check out 2.1.129.
>
> i obviously didn't explain myself :-)
>
> i have 1.1.1
> i put it in rcs
> THEN i get 1.1.47
> so i put that in rcs
> NOW i get 1.1.x where 1 < x < 47
>
> how do i insert that inbetween 1.1.1 and 1.1.47?
That's exactly the way you do _not_ want to do it. CVS doesn't care about the
internal RCS version numbers. Yes, I made the same mistake some time ago.
If a file isn't changed in between Linux release 2.1.128 and 2.1.129, it will
have the same (internal) RCS version number in both releases.
CVS uses symbolic names (tags) to link the various RCS version numbers with a
global release name.
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uyt...@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
Simon Kenyon
>> i have 1.1.1
>> i put it in rcs
>> THEN i get 1.1.47
>> so i put that in rcs
>> NOW i get 1.1.x where 1 < x < 47
>>
>> how do i insert that inbetween 1.1.1 and 1.1.47?
>
> That's exactly the way you do _not_ want to do it. CVS doesn't care about the
> internal RCS version numbers. Yes, I made the same mistake some time ago.
> If a file isn't changed in between Linux release 2.1.128 and 2.1.129, it will
> have the same (internal) RCS version number in both releases.
>
> CVS uses symbolic names (tags) to link the various RCS version numbers with a
> global release name.
then i can see no good reason to stick it in cvs
if i cannot use it to track the changes to a particular FILE as the kernel moved
from version to version (and to be able to ask questions like what changed in mm.c
from 2.0.0 and 2.1.0 for example) what is the point of storing anything under cvs
somebody else has explained to me what i have to do to do the "out of order"
insertions into rcs - it is not a pretty sight :-(
--
simon
Geert Uytterhoeven
> >> i have 1.1.1
> >> i put it in rcs
> >> THEN i get 1.1.47
> >> so i put that in rcs
> >> NOW i get 1.1.x where 1 < x < 47
> >>
> >> how do i insert that inbetween 1.1.1 and 1.1.47?
> >
> > That's exactly the way you do _not_ want to do it. CVS doesn't care about the
> > internal RCS version numbers. Yes, I made the same mistake some time ago.
> > If a file isn't changed in between Linux release 2.1.128 and 2.1.129, it will
> > have the same (internal) RCS version number in both releases.
> >
> > CVS uses symbolic names (tags) to link the various RCS version numbers with a
> > global release name.
>
> then i can see no good reason to stick it in cvs
> if i cannot use it to track the changes to a particular FILE as the kernel moved
> from version to version (and to be able to ask questions like what changed in mm.c
> from 2.0.0 and 2.1.0 for example) what is the point of storing anything under cvs
cvs diff -r linus-2-0-0 -r linus-2-1-0 mm.c
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uyt...@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
Guest section DW
I just put all kernel versions since 1.0 up for ftp.
(That is the part I have complete - earlier things are fragmentary.)
Andries
The URL is ftp://ftp.win.tue.nl/pub/linux/kernel.archive
Guest section DW
> Would be easy to get the PDP-11 simulator running under Linux;
> I've suggested to Bob Supnik that it would be a good thing to do.
You can do it yourself. No effort is required.
# unix5
Boot unix with @unix; login as root.
PDP-11 simulator V2.3b
@unix
login: root
# ls -l /bin/sh
-rwxr-xr-x 1 bin 5738 Nov 26 18:13 /bin/sh
#
Larry McVoy
: i have 1.1.1
: i put it in rcs
: THEN i get 1.1.47
: so i put that in rcs
: NOW i get 1.1.x where 1 < x < 47
:
: how do i insert that inbetween 1.1.1 and 1.1.47?
: can bitmover help?
Of course. You can also teach CVS to do this but it would be a pretty
big rewrite and you'd end up with BitKeeper anyway.
Here is how you solve this problem:
Think of each file as a graph, with each node as a delta.
Make an invariant which is that the parent of a node never
changes.
Only add stuff to your file if the parent node is in your file.
So here's the way BitKeeper implements this:
Each node has a unique key which is a string with the following
fields from the delta entry:
user
hostname
date (including minutes west of GMT)
pathname
When you send out the 1.1.47 diffs, it includes the key for
1.1.46. When you try and apply these diffs into your file,
the application program (it's called takepatch) will fail if
it doesn't find the 1.1.46 node.
This generalizes to handling branches, etc. It's very simple graph
manipulations. The place where everyone screws up can always be described
as a violation of the parent/child invariant.
You may not like that you can't apply 1.1.47 as a child of 1.1.1 but
that's the way it has to work. Anyone who tells you differently is
just telling you what you want to hear.
Theodore Y. Ts'o
From: Riley Williams <r...@bigfoot.com>
Judging by that list, there's still quite a few missing versions, so
if anybody has copies of the remaining versions, I'd certainly be
interested therein...
Actually, there aren't that many missing. The Linux version number took
a jump between 0.12 to 0.95, since Linus thought 1.0 was just around the
corner. In reality, things didn't quite work that way, which is why we
started going to 3-part version number.
One obvious way of demonstrating that there isn't much time elapsed
between the 0.12 kernel and the 0.95 kernel is that they are very
similar in size (although of course the 0.95 kernel is a little bigger. :-)
- Ted
Theodore Y. Ts'o
preserved.
What is much less well-preserved is the old original distributions.
That's because they are bigger, and tended to change over time,
sometimes without necessarily having distinct version numbers.
But something which would definitely worth doing is to compile a history
of all of the various distributions, with beginning and ending dates,
when it was the most popular, who was responsible for doing the
distribution, what key feature(s) the distributions introduced, which
distributions were descended from other distributions, etc.
Guest section DW
But now that I looked anyway, I have collected
all kernels I can find, with the earliest time stamps
I can find, in ftp://ftp.win.tue.nl/pub/linux/kernel.archive .
(Added in a few amusing files, like the License for 1.2.)
Additions are welcome.
Missing for example: 0.99pl13X for all letters X except X=k,
and all earlier sublevels of 0.99.
I have a few boot- and root disks from the 0.97-0.99 era.
May try to put up complete systems later.
Andries
Hans-Joachim Baader
> > Is there a note about which is the oldest kernel version one can
> > actually compile using recent tools (gcc-2.7.2+, binutils-2.8+,
> > make-3.7x+)?
>
>I havenae had a look, sorry...
1.0.9 is compilable with some patches.
I have created a "mega-patch" that contains all the patches to 1.0.9
I'm aware of. This kernel actually did run on my Pentium notebook,
without PCMCIA though...
I should perhaps put it on my web page to give it wider testing...
>
> >> 1.2.0 through 1.2.13
>
> > I once had 1.2.13pl9 and pl10 for m68k Amigas. I'm not sure
> > whether these pl releases were official kernels which had *then*
> > m68k patches applied to them.
I have all kernels since 0.99 in case someone needs them ;-)
> > I also once had at least one kernel which had PATCHLEVEL= or
> > SUBLEVEL= set to "99" in the Makefile. Not sure which version
> > this actually was (it was >=1.2.x), but I remember that the
> > numbers in its tar filename mentioned a slightly different
> > version. Maybe a lookup in the kernel archive could help.
Probably 1.99.x, aka 2.0pre
hjb
--
"Every use of Linux is a proper use of Linux."
-- John "Maddog" Hall, Keynote at the Linux
Kongress in Cologne
Harald Koenig
> On Mon, 23 Nov 1998, Simon Kenyon wrote:
> > On 23-Nov-98 Riley Williams wrote:
> > > I've been looking into setting up a CVS tree that will contain the
> > > full kernel source history...
> > > Put them in a CVS archive, and you replace "sum of kernel source
> > > archive sizes" with "sum of upgrade patch file sizes", and thus
> > > massively reduce the size of the result...
> > > I would suspect the result will fit on a ZipDisk, never mind a CD, but
> > > I'll not know for sure until I get it set up...
> > > Are there any CVS experts out there?
> >
> > now we're getting somewhere
> > trouble is - as the puzzle unfolds, what do you do about the situation where an
> > intermediate release turns up
> >
> > say we have 1.1.1, 1.1.3, 1.1.4
> > put them in cvs and all of a sudden 1.1.2 appears from some kindly soul
> > can cvs/rcs/sccs (you choose) handle this?
>
> That's why we have tags. After checking in 2.1.129, you say
>
> cvs tag linus-2-1-129
>
> After that you can say
>
> cvs co linus-2-1-129
>
> to check out 2.1.129.
correct.
but in the above example, 1-1-2 would be stored as a diff relative to 1-1-4,
and if 1-1-5 will be checked in later, it will be stored as diffs relative
to 1-1-2 resuling in a somewhat suboptimal storage method, right ?
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koe...@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
Riley Williams
> I've just had a look at the SunSite-UK mirror thereof, and note the
> following kernel tarballs thereon, in various directories:
This suggests to me that the stated kernel tarballs are missing...so
if you can cross off the ones that never existed, it'd be appreciated.
> 0.01
=> 0.02 through 0.09
> 0.10
> 0.11
> 0.12
=> Linus jumped the kernel version numbers at this point...
> 0.95
> 0.95a
=> 0.96
> 0.96a (plus patches 2, 3 and 4)
> 0.96b (plus patches 1 and 2)
> 0.96c (plus patches 1 and 2)
> 0.96c+
> 0.97
=> 0.98*
> 0.99 (plus patches 1 through 9 and 11 through 13)
> 0.99.1 through 0.99.7
> 0.99.7A
> 0.99.8 through 0.99.11
> 0.99.12 (plus linux-0.99.12.small-patch)
> 0.99.13
=> 0.99.14
> 0.99.15
=> Did 0.99.16 get renamed 1.0 ?
> 1.0 (plus patches 1 through 9)
=> 1.1
=> 1.1.0 through 1.1.12
> 1.1.13
=> 1.1.14 through 1.1.22
> 1.1.23
=> 1.1.24 through 1.1.28
> 1.1.29
=> 1.1.30 through 1.1.32
> 1.1.33
=> 1.1.34
> 1.1.35
=> 1.1.36 through 1.1.44
> 1.1.45
=> 1.1.46 through 1.1.51
> 1.1.52
=> 1.1.53 through 1.1.58
> 1.1.59
=> 1.1.60 through 1.1.62
> 1.1.63 1.1.64
=> 1.1.63 through 1.1.66
> 1.1.67
=> 1.1.68 and 1.1.69
> 1.1.70 1.1.71
=> 1.1.72
> 1.1.73 1.1.74 1.1.75 1.1.76
=> 1.1.77
> 1.1.78 through 1.1.95
> 1.2.0 through 1.2.13
> 1.3.0
=> 1.3.1
> 1.3.2 through 1.3.100
> pre2.0.1 through pre2.0.14
> 2.0
> 2.0.1 through 2.0.36
> 2.1.0 through 2.1.24
=> 2.1.25 and 2.1.26
> 2.1.27 through 2.1.129
Also, of course, kernels post 2.0.36 and 2.1.129 hadn't appeared when
the original list was posted, so can be ignored for the purposes of
this message...
Best wishes from Riley.
Geert Uytterhoeven
> Geert Uytterhoeven wrote:
> > On Mon, 23 Nov 1998, Simon Kenyon wrote:
> > > On 23-Nov-98 Geert Uytterhoeven wrote:
> > > >> say we have 1.1.1, 1.1.3, 1.1.4
> > > >> put them in cvs and all of a sudden 1.1.2 appears from some kindly soul
> > > >> can cvs/rcs/sccs (you choose) handle this?
> > > >
> > > > That's why we have tags. After checking in 2.1.129, you say
> > > >
> > > > cvs tag linus-2-1-129
> > > >
> > > > After that you can say
> > > >
> > > > cvs co linus-2-1-129
> > > >
> > > > to check out 2.1.129.
> > >
> > >
> > > i put it in rcs
> > > THEN i get 1.1.47
> > > so i put that in rcs
> > > NOW i get 1.1.x where 1 < x < 47
> > >
> > > how do i insert that inbetween 1.1.1 and 1.1.47?
> >
> > internal RCS version numbers. Yes, I made the same mistake some time ago.
> > If a file isn't changed in between Linux release 2.1.128 and 2.1.129, it will
> > have the same (internal) RCS version number in both releases.
> >
> > CVS uses symbolic names (tags) to link the various RCS version numbers with a
> > global release name.
>
> (and this is surely sliding OT rapidly) you will end up with a *much*
> larger source-control database if you check revs in the wrong order ?
Yes.
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uyt...@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
Neil Conway
Neil
Alex Buell
> I have a few boot- and root disks from the 0.97-0.99 era.
> May try to put up complete systems later.
Question is: Will 0.01 work? Can I just install it and see it run like
shit off a shovel?! :)
This is a question that's been bugging me for a while. What's the EARLIEST
kernel that will still work with all the wonderful stuff that we have
including glibc2? :)
I'll be hornsblowed if 0.01 will run..
Cheers,
Alex.
---
/\_/\ Legalise cannabis now!
( o.o ) Grow some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.
Check out http://www.tahallah.demon.co.uk
Linux lo-pc3035a 2.1.129 #9 Thu Nov 19 14:23:26 EST 1998
One Intel Pentium 166MHz processor, 66.36 total bogomips, 16M RAM
System library 5.4.44
Johnny Tevessen
[recent tools]
> 1.0.9 is compilable with some patches.
> I should perhaps put it on my web page to give it wider testing...
I guess these are no "official" patches, so could they be included
in the kernel archive?
> > > I also once had at least one kernel which had PATCHLEVEL= or
> > > SUBLEVEL= set to "99" in the Makefile. Not sure which version
> > > this actually was (it was >=1.2.x), but I remember that the
> > > numbers in its tar filename mentioned a slightly different
> > > version. Maybe a lookup in the kernel archive could help.
>
> Probably 1.99.x, aka 2.0pre
Another thing to mention for the yet-to-write history file.
ciao,
johnny
--
Trust no-one.
-
Guest section DW
From: "J. S. Connell" <an...@canuck.gen.nz>
On Mon, 23 Nov 1998, Guest section DW wrote:
> You can do it yourself. No effort is required.
May I ask where you found UNIX v5 and a PDP-11 simulator?
There are several around.
I think the one I showed was from
ftp://ftp.digital.com/pub/DEC/sim/sources/
Andries
Guest section DW
This suggests to me that the stated kernel tarballs are missing...so
if you can cross off the ones that never existed, it'd be appreciated.
Roughly speaking, nothing is missing since 0.10,
except possibly for testreleases, prereleases, intermediate releases
like 0.99pl12d, and the like.
Go to ftp.funet.fi to find a good collection.
Then look at ftp.win.tue.nl to find an almost identical collection,
with very few things added. (But with the patches only, not the
full kernels, except for the early ones.)
Larry McVoy
: +-----
: | You may not like that you can't apply 1.1.47 as a child of 1.1.1 but
: | that's the way it has to work. Anyone who tells you differently is
: | just telling you what you want to hear.
:
: That implies that Bitkeeper can only be used for complete trees. So we
: can't use it until we've found *all* the kernel revisions. :-( OTOH we're
: not really talking about revision control, so Bitkeeper or other complex
: revision control packages aren't necessarily the appropriate tools for the
: task.
:
: It does work to ignore relationships between revisions and check them in in
: any order, then use e.g. CVS tags to identify particular kernel releases.
: The underlying RCS files will not be optimal, but it will work --- because
: this is not really a revision control tree we're discussing, but a revision
: history. We don't need (or intend) to store file revisions that don't
: correspond to kernel releases, or to track/"micromanage" current
: development. Every so often the tree could be dumped and rebuilt in the
: proper order to reduce the size of the RCS files, but this wouldn't have to
: be done every time a new kernel release were found and added to the tree.
:
: If we were going to use this as the kernel development tree as well as a
: historical reference, it would indeed be an absolute nightmare and
: unworkable in practice. But we aren't, so we can get away with an abuse of
: the relationship between CVS and RCS.
With no offense intended, I disagree.
The whole point of having things under revision control is so that you
can browse them, in the order that the events happened, not in some random
order which corresponds to when you happened to find some old kernel.
As to the tree itself, I'll take responsibility for checking in what we have
archived to date and providing that tree as a basis for future work. Once
we have that basis, there are no ordering problems, at least none that you
need to get around.
Let me try and be a bit more clear about that last claim. It's true that
if you are at version 1.100 in your copy of the source and patch which
consists of the diffs from 1.200 .. 1.203 comes by, BitKeeper will not
allow you to patch that into your tree. Under no circumstances, not even
if Cindy Crawford showed up and begged, would I change that behaviour (she's
welcome to show up and try to convince me, however :-)
The reason is that "the source" is a distributed thing. There are
copies of the same files all over the world. You guys all want that
managed well so that you can do your work in a distributed fashion with
a minimal amount of fuss. If you start changing around the order of
events in the revision control graph, there is nothing that any tool can
do to help you. On the other hand, if you don't violate the ordering,
then I can answer questions, programatically, like "does the latest
release from Linus have everything that is in my tree or not?"
Another example of where this ordering can be an issue is Linus'
infamous editing of unified diffs before he applies them to his tree.
That is a problem because the diffs represent the events (deltas) made
by someone else. When Linus edits those diffs, that's a new event.
If he applies the modified diffs before applying the pristine diffs,
then when you ask "are my diffs in the tree?" the answer will be "no"
because your diffs aren't in the tree. What is in the tree is your diffs
plus Linus' changes, *as one delta*. And that delta is different than
the one delta you made in your tree.
So how do we get around this? The correct set of changes is whatever
you did plus whatever Linus did as two distinct events. But Linus is
in a hurry, so he wants to *think* that he can just edit the diffs
and apply them. So I'll make a little tool, maybe we can call the
"linustool", which lets him hack on the diffs and then applies them for
him. But what it really does is save away a copy of the diffs, get the
(possibly hacked) diffs from Linux when he says "apply", diff the diffs,
if they are changed, apply the first set as your changes, and then apply
the mods to that set as his change. It sounds complicated and I'm sure
it will be a little dicey, but I'm also sure I can build that tool.
So everyone is happy - Linus gets to work the way he wants and we can
still preserve the invariants required to have a distributed source base.
If this is clear as mud, you're welcome to send me mail with questions or
if hte list can stand it, we can discuss it here.
Cheers,
--lm
Brandon S. Allbery KF8NH
+-----
| You may not like that you can't apply 1.1.47 as a child of 1.1.1 but
| that's the way it has to work. Anyone who tells you differently is
| just telling you what you want to hear.
+--->8
That implies that Bitkeeper can only be used for complete trees. So we
can't use it until we've found *all* the kernel revisions. :-( OTOH we're
not really talking about revision control, so Bitkeeper or other complex
revision control packages aren't necessarily the appropriate tools for the
task.
It does work to ignore relationships between revisions and check them in in
any order, then use e.g. CVS tags to identify particular kernel releases.
The underlying RCS files will not be optimal, but it will work --- because
this is not really a revision control tree we're discussing, but a revision
history. We don't need (or intend) to store file revisions that don't
correspond to kernel releases, or to track/"micromanage" current
development. Every so often the tree could be dumped and rebuilt in the
proper order to reduce the size of the RCS files, but this wouldn't have to
be done every time a new kernel release were found and added to the tree.
If we were going to use this as the kernel development tree as well as a
historical reference, it would indeed be an absolute nightmare and
unworkable in practice. But we aren't, so we can get away with an abuse of
the relationship between CVS and RCS.
--
brandon s. allbery [os/2][linux][solaris][japh] all...@kf8nh.apk.net
system administrator [WAY too many hats] all...@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
Kiss my bits, Billy-boy.
Brandon S. Allbery KF8NH
+-----
| On 23-Nov-98 Geert Uytterhoeven wrote:
| > CVS uses symbolic names (tags) to link the various RCS version numbers with
| a
| > global release name.
|
| if i cannot use it to track the changes to a particular FILE as the kernel mo
| ved
| from version to version (and to be able to ask questions like what changed in
| mm.c
| from 2.0.0 and 2.1.0 for example) what is the point of storing anything under
| cvs
But you can. You use CVS commands to do it, and identify the file versions
by their CVS tags; CVS maps the tags to the RCS revisions(*) and you get
what you wanted *regardless of what RCS versions are involved*.
cvs diff -rLINUX_0_99p14 -rLINUX_2_1_129 drivers/char/console.c
is perfectly meaningful in this system and will give you the differences
between the 0.99p14 and 2.1.129 versions of drivers/char/console.c. Which
is the whole point of CVS.
(*) Actually, RCS does it: CVS tags are simply RCS tags which CVS keeps in
sync across multiple files, since RCS doesn't have the concept of multiple
related files.
If you insist on using RCS version numbers you'll have a problem anyway: in
RCS you have to treat revision numbers as dotted pairs. Well, you don't
absolutely *have* to, but various commands assume <branchID, revision>
relationships between pairs of numbers, so "1.2.129" could not be easily
represented in RCS except as 1.1.2.1.129.1. You DON'T want to go there,
trust me.
Brandon S. Allbery KF8NH
| if you are at version 1.100 in your copy of the source and patch which
| consists of the diffs from 1.200 .. 1.203 comes by, BitKeeper will not
Here, I think, is the difference. You're thinking in terms of patches as
the "base unit"; I'm thinking of entire source trees. Given a patch to
produce a different kernel version, I would release the appropriate version,
apply the patch, and check it in as the new version. I'm *not* thinking of
file-by-file browsing because the most interesting stuff isn't there --- we
are most likely to find full source releases, not patches sitting around,
and it's unlikely that interim patches for older releases (i.e. the
equivalent of 2.0.35ac*) have survived. And, as you noted, even the patches
aren't guaranteed to produce official released source trees.
Given the limitations of what is available to us, I don't see an urgent need
to try to reconstruct an actual development tree. Future kernel development
via Bitkeeper or etc. is probably a very good idea, but trying to force
earlier kernels into the mold is more likely to be an exercise in
frustration than anything else. If we already had a reliable CVS tree
covering a significant part of the development cycle (vger doesn't, as
Linus's releases don't tie to it) then migrating it to Bitkeeper would make
sense, but as is it's just going to frustrate you unnecessarily....
--
brandon s. allbery [os/2][linux][solaris][japh] all...@kf8nh.apk.net
system administrator [WAY too many hats] all...@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
Kiss my bits, Billy-boy.
-
Geert Uytterhoeven
> On Tue, 24 Nov 1998, Guest section DW wrote:
> > I have a few boot- and root disks from the 0.97-0.99 era.
> > May try to put up complete systems later.
>
> Question is: Will 0.01 work? Can I just install it and see it run like
> shit off a shovel?! :)
>
> This is a question that's been bugging me for a while. What's the EARLIEST
> kernel that will still work with all the wonderful stuff that we have
> including glibc2? :)
Since your glibc2 is an ELF binary, 0.01 won't work for sure.
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uyt...@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
Larry McVoy
: via Bitkeeper or etc. is probably a very good idea, but trying to force
: earlier kernels into the mold is more likely to be an exercise in
: frustration than anything else.
I'm not sure what the problem is - I have no intent or interest in recreating
all the steps between releases, but we have all the released version of the
kernels. So what's to prevent from getting the first one, checking it in,
check in the second release, etc.? What's so hard about that?
Alexander
Sorry, I would have replied to this thread sooner, but my mail gateway
was on the fritz.
>>>>> "Neil" == Neil Conway <nconwa...@ukaea.org.uk> writes:
Neil> The real problem doesn't really go away though. Unless I
Neil> miss my guess (and this is surely sliding OT rapidly) you
Neil> will end up with a *much* larger source-control database if
Neil> you check revs in the wrong order ?
The way that I would accomplish what you are trying to do, is by the
following:
Check in the new source on the same branch as the lowest and _closest_
version number. If said version number is not at the head of the
branch in question, branch at said version number.
If that didn't make sense, here is an example (remember, all version numbers
you see are Linux source versions, and _NOT_ RCS/CVS file revisions):
For instance, let's say that you have Linux kernels 1.1.1, 1.1.5, and 1.1.6,
your tree could look like this (w/ each * being the state of the tree at
the given tag):
linux-1.1.1 linux-1.1.5 linux-1.1.6
----*----------------*------------*------->
You then all of a sudden receive a copy of linux-1.1.2. You now branch
at the closest and lowest revision on the tree (linux-1.1.1), since it isn't
at the head of the branch, and check-in the new Linux version (linux-1.1.2)
on the head of the new branch. Your tree now looks like:
linux-1.1.1 linux-1.1.5 linux-1.1.6
----*----------------*------------*------->
\ linux-1.1.2
`-----*---->
Then, by some quirk of fate, you receive linux-1.1.4, so, you check-in the
linux-1.1.4 code base at the point of the closest smaller version number. Your
tree now looks like the following:
linux-1.1.1 linux-1.1.5 linux-1.1.6
----*----------------*------------*------->
\ linux-1.1.2 linux-1.1.4
`-----*-----------*------>
Someone sends you linux-1.1.3, so you branch at linux-1.1.2, and check-in
linux-1.1.3 on the new branch:
linux-1.1.1 linux-1.1.5 linux-1.1.6
----*----------------*------------*------->
\ linux-1.1.2 linux-1.1.4
`-----*-----------*------>
\ linux-1.1.3
`-----*--->
I hope this made sense. Good luck w/ the Linux history repository.
Alexander
Andrew J. Scott
> Hi Simon.
>
> > The History of the Linux Operating System
>
> > I'm going to start to pull together anything and everything that I >
> can find about the history of the Linux OS.
>
> ===8<=== CUT ===>8===
>
> What I'd like to see is some of the early releases of Linux, just out of
> curiosity. Problem is, they all appear to be long since filed in the old
> circular file...
>
> Best wishes from Riley.
How old? The kernels, back to 1.0 are available on some ftp sites. tsx-
11.mit.edu has v1.0, v1.2.xx as well as current kernels.
------------------Mailed via Pegasus 2.53 & Mercury 1.30---------------
A.J....@casdn.neu.edu Fax (617)373-2942
Andrew Scott Tel (617)373-5278 _
Northeastern University--138 Meserve Hall / \ /
College of Arts & Sciences-Deans Office / \ \ /
Boston, Ma. 02115 http://www.casdn.neu.edu / \_/
Riccardo Facchetti
> > This is a question that's been bugging me for a while. What's the EARLIEST
> > kernel that will still work with all the wonderful stuff that we have
> > including glibc2? :)
>
> Since your glibc2 is an ELF binary, 0.01 won't work for sure.
I wouldn't do that if you care your data. Filesystems (expecially ext2)
changed a lot since the epoch so you may well end up with trashed
partitions. Don't experiment with kernels on your HDs. Use floppy but
don't try to mount partitions.
Ciao,
Riccardo.
Brandon S. Allbery KF8NH
| all the steps between releases, but we have all the released version of the
| kernels. So what's to prevent from getting the first one, checking it in,
But we don't. 0.99.14, for example, is noticeably missing from the list ---
and I remember 0.99.14 very well because it was the first kernel that was
stable enough for production use by most then Linuxers, marred only by small
issues such as (IIRC) ATI and S3 video cards vs. COM4. And it's right smack
in the middle of the list of released kernels.
--
brandon s. allbery [os/2][linux][solaris][japh] all...@kf8nh.apk.net
system administrator [WAY too many hats] all...@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
Kiss my bits, Billy-boy.
-
Riley Williams
> questions or if the list can stand it, we can discuss it here.
Maybe I'm just super-dense or something, but...
Q. Why is a tool like that needed? Surely one can simply produce a
copy of the tree as it exists after one's own diff is applied,
and a separate copy of the tree as released by Linus, and just
diff one against the other? It's not exactly hard...
Best wishes from Riley.
Brandon S. Allbery KF8NH
, G
reaves Tristan TM writes:
+-----
| > trees. So we can't use it until we've found *all* the kernel revisions.
|
| the correct order. So all the patch relationships and whatever are
| there correctly.
|
| So now what happens when an intermediate version comes along?
|
| Easy.
|
| 2. Destroy the CVS tree. Recreate it from scratch using the brand new
| set of sources you have. In order.
+--->8
Certainly this can be done. It will require at least 3 to 5 times the disk
space during the rebuild that the final repository uses, and it will be
time-consuming to rebuild it as new releases are found. Which is why we
want to minimize the amount of rebuilding that goes on, as in my original
proposal. (Maybe you have that much disk space and CPU cycles to donate,
but I suspect nobody else does.)
Mind you, I'm not against the use of BitKeeper for the Linux source
repository --- I just think it's not appropriate for this task at the
present time, kind of like swatting a fly with a sledgehammer. It might
(heck, would) be worth merging the historical CVS tree into the
BitKeeper-based current development tree once we have all the releases we
know about (or are likely to find), but I'm not sure it's worth the effort
to try to build a proper tree from it until we *can* build a proper tree
from the historical releases. Until then, the historical tree could be made
available without requiring quite as much maintenance effort.
BTW, was anyone else somewhat shocked to discover that apparently nobody has
a copy of what was then described by some as the "first really usable Linux
kernel", namely 0.99.14? I may go rooting through my ancient backup tapes
(if they haven't succombed to bitrot) over the weekend and see if I have an
0.99.14 tree around still.
--
brandon s. allbery [os/2][linux][solaris][japh] all...@kf8nh.apk.net
system administrator [WAY too many hats] all...@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
Kiss my bits, Billy-boy.
-
Henrik Olsen
> In message <1998112504...@bitmover.com>, Larry McVoy writes:
> +-----
> | I'm not sure what the problem is - I have no intent or interest in recreating
> | all the steps between releases, but we have all the released version of the
> | kernels. So what's to prevent from getting the first one, checking it in,
> +--->8
>
> But we don't. 0.99.14, for example, is noticeably missing from the list ---
> and I remember 0.99.14 very well because it was the first kernel that was
> stable enough for production use by most then Linuxers, marred only by small
> issues such as (IIRC) ATI and S3 video cards vs. COM4. And it's right smack
> in the middle of the list of released kernels.
Have a look at ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/old-versions/, it
has:
linux-0.95a.tar.gz
linux-0.95c+.tar.gz ł
pre-0.96.tar.gz
linux-0.96c.tar.gz
linux-0.97.6.tar.gz
linux-0.97.patch1.gz
linux-0.97.patch2.gz
linux-0.97.patch3.gz
linux-0.97.patch4.gz
linux-0.97.patch5.gz
linux-0.97.patch6.gz
linux-0.97.tar.gz
linux-0.98.tar.gz
linux-0.98.1.tar.gz
linux-0.98.2.tar.gz
linux-0.98.3.tar.gz
linux-0.98.4.tar.gz
linux-0.98.5.tar.gz
linux-0.98.6.tar.gz
linux-0.98.6-0.99.diffs.gz
linux-0.99.tar.gz
linux-0.99.1.tar.gz
linux-0.99.2.tar.gz
linux-0.99.3.tar.gz
linux-0.99.4.tar.gz
linux-0.99.5.tar.gz
linux-0.99.6.tar.gz
linux-0.99.7.tar.gz
linux-0.99.7A.tar.gz (Had Linus been reading Pratchett?)
linux-0.99.8.tar.gz
linux-0.99.9.tar.gz
linux-0.99.10.tar.gz
linux-0.99.11.tar.gz
linux-0.99.12.tar.gz
linux-0.99.13.tar.gz
linux-0.99.14.tar.gz
linux-0.99.15.tar.gz
--
Henrik Olsen, Dawn Solutions I/S
URL=http://www.iaeste.dk/~henrik/
Get the rest there.
Alex Buell
> But we don't. 0.99.14, for example, is noticeably missing from the
> list --- and I remember 0.99.14 very well because it was the first
> kernel that was stable enough for production use by most then
> Linuxers, marred only by small issues such as (IIRC) ATI and S3 video
> cards vs. COM4. And it's right smack in the middle of the list of
> released kernels.
Ah yeah, the infamous COM4 bug with S3 chipsets. Seems some fuckwit used
the usual COM4 I/O port as one of its I/O registers. Ahh, that particular
chipset designer should have been taken out and made to use Microsoft
products in eternity (with a Windows 95 Beta!).
Cheers,
Alex
--
/\_/\ Legalise cannabis now!
( o.o ) Grow some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.
http://www.tahallah.demon.co.uk - *new* - rewritten for text browser users!
Linux tahallah.demon.co.uk 2.1.129 #63 SMP Sat Nov 21 23:52:03 EST 1998
Two Intel Pentium Pro 166MHz processors, 331.78 total bogomips, 48M RAM
System library 2.0.6
David Luyer
Does anyone actually know of any official Linux kernel releases missing from
ftp.kernel.org? If so, could you just post a list of them so that people can
look for them - if not, just make a CVS tree of all the releases to date (maybe
waiting for 2.2.0 and putting that as the last entry), make a CD image and be
happy.
David.
David Luyer
> RCS you have to treat revision numbers as dotted pairs. Well, you don't
> absolutely *have* to, but various commands assume <branchID, revision>
> relationships between pairs of numbers, so "1.2.129" could not be easily
> represented in RCS except as 1.1.2.1.129.1. You DON'T want to go there,
> trust me.
If RCS supports branches, things become awfully trivial.
A new, old tree which shows up can be entered efficiently as a branch
off the kernel revision before it? Then why are people still going on about
how impossible it is to insert between revisions? Define a decent tree
structure and you're all done.
Root of tree: nothing
Branch for each major revision development kernel
(eg -- 2.1.0 is represented as a diff from 2.0.0, but 2.0.0 is a
diff from 1.3.99)
Further revisions for each _official_ patch on top of them
Sub-branch for each pre-patch on top of them
Define the starting tree to be what's currently on ftp.kernel.org and
enter any 'newly found' patches as sub-branches just like pre-patches.
And, wow, you're done. No need to keep discussing it, just do it.
If this isn't possible, then you may have a problem if 2.0.37 comes out
after you form your tree, just the same as you'd have a problem if you
found an official linux-0.50 after you form your tree. And when 2.3.x is
in development, 2.2.x is almost certain to be still getting patches.
Khimenko Victor
> On Wed, 25 Nov 1998, Geert Uytterhoeven wrote:
>> > This is a question that's been bugging me for a while. What's the EARLIEST
>> > kernel that will still work with all the wonderful stuff that we have
>> > including glibc2? :)
>>
>> Since your glibc2 is an ELF binary, 0.01 won't work for sure.
> I wouldn't do that if you care your data. Filesystems (expecially ext2)
> changed a lot since the epoch so you may well end up with trashed
> partitions. Don't experiment with kernels on your HDs. Use floppy but
> don't try to mount partitions.
Especially since Linux 1.0 (and early) dislike IDE drives > 512Mb :-))
Mike A. Harris
> > I'm going to start to pull together anything and everything that I
> > can find about the history of the Linux OS.
>
>===8<=== CUT ===>8===
>
>What I'd like to see is some of the early releases of Linux, just out
>of curiosity. Problem is, they all appear to be long since filed in
>the old circular file...
You can find old releases on practically any ftp site that
carries the kernel. I believe the directory is called
old-kernels or "history" or something like that...
--
Mike A. Harris - Computer Consultant - Linux advocate
Linux software galore: http://freshmeat.net
Brandon S. Allbery KF8NH
Ale
x Buell writes:
+-----
| On Wed, 25 Nov 1998, Brandon S. Allbery KF8NH wrote:
| > Linuxers, marred only by small issues such as (IIRC) ATI and S3 video
| > cards vs. COM4. And it's right smack in the middle of the list of
|
| the usual COM4 I/O port as one of its I/O registers. Ahh, that particular
| chipset designer should have been taken out and made to use Microsoft
| products in eternity (with a Windows 95 Beta!).
Not exactly.
The ATI and S3 chipsets started out as enhancements of IBM's 8514/A video
card. But the 8514/A was designed for Microchannel, which addresses the
entire I/O space. So the 8514/A used several registers with addresses
0xX2e8, for several values of X.
The ISA bus only has 10 I/O address lines, so I/O addresses above 0x03FF
effectively wrap around. The 8514/A ports ended up aliased to 0x02e8....
Arguably the bad design decision was to base an ISA card on the 8514/A. It
couldn't be IBM's decision because (a) there was no wraparound on
Microchannel and (b) Microchannel is perfectly capable of sharing IRQs, so
COM4 could be on IRQ3 as originally documented without conflicting with COM2
(and (c) they never intended 8514/A for use on ISA systems).
--
brandon s. allbery [os/2][linux][solaris][japh] all...@kf8nh.apk.net
system administrator [WAY too many hats] all...@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
Kiss my bits, Billy-boy.
-
Daniel Engstrom
> Ah yeah, the infamous COM4 bug with S3 chipsets.
very address first.
> Seems some fuckwit used the usual COM4 I/O port as one of its I/O
> registers.
identical to 0x3E8, which is the COM4 base port. You'll need an
el-cheapo serial board with 10-bit address decode only to be bitten by
this.
> Ahh, that particular chipset designer should have been taken out and made to use Microsoft
> products in eternity (with a Windows 95 Beta!).
for i/o port accesses was enough for all future.
/Daniel
--
Gabriel Paubert
On Wed, 25 Nov 1998, Alex Buell wrote:
> On Wed, 25 Nov 1998, Brandon S. Allbery KF8NH wrote:
>
> > But we don't. 0.99.14, for example, is noticeably missing from the
> > list --- and I remember 0.99.14 very well because it was the first
> > kernel that was stable enough for production use by most then
> > Linuxers, marred only by small issues such as (IIRC) ATI and S3 video
> > cards vs. COM4. And it's right smack in the middle of the list of
> > released kernels.
>
> Ah yeah, the infamous COM4 bug with S3 chipsets. Seems some fuckwit used
> the usual COM4 I/O port as one of its I/O registers. Ahh, that particular
> chipset designer should have been taken out and made to use Microsoft
> products in eternity (with a Windows 95 Beta!).
>
For your edification, here is the lists of I/O ports used by a S3 Trio64
during BIOS init (collected under an x86 emulator for PPC which registers
all I/O ports ever accessed, so it must be pretty accurate):
0042-0043 /* (Yes it uses one timer)
0061-0061 */
0102-0102
03b4-03b5
03b8-03b8
03c0-03c0
03c2-03c6
03c8-03c9
03cc-03cc
03ce-03cf
03d4-03d5
03da-03da
42e8-42e9 /* Now these ones are interesting: the low order 10 bits
46e8-46e8 * are 0x2e8-0x2e9, which conflicts with standard COM4,
4ae8-4ae8 * because serial boards traditionnally only decode the
82e8-82e9 * 10 low order bits of I/O address. On modern PCI mobo,
86e8-86e9 * the ISA bridge uses so called subtractive decoding
96e8-96e9 * only claiming the cycle if no other device responds
9ae8-9ae9 * which hides the problem. However, IIRC the original
a6e8-a6e9 * culprit is IBM with the 8514/A which was designed (sic)
aae8-aae9 * this way, others only followed. (And this list is only
bae8-bae9 * the list of ports used to init the board in VGA text
bee8-bee9 * mode).
*/
Gabriel
Alex Buell
> The ISA bus only has 10 I/O address lines, so I/O addresses above 0x03FF
> effectively wrap around. The 8514/A ports ended up aliased to 0x02e8....
Ah, now I stand corrected, looks like substandard serial port cards were
the problem in the first place. No wonder I had some problems :o) Well one
does learn something new everyday. IIRC, it was the poor quality serial
port cards that has the broken 10bit address decoding circuitry. ISA buses
doesn't provide the address decoding stuff I think, it's down to the ISA
card to do it, I believe.
Cheers,
Alex
--
/\_/\ Legalise cannabis now!
( o.o ) Grow some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.
http://www.tahallah.demon.co.uk - *new* - rewritten for text browser users!
Linux tahallah.demon.co.uk 2.1.129 #63 SMP Sat Nov 21 23:52:03 EST 1998
Two Intel Pentium Pro 166MHz processors, 331.78 total bogomips, 48M RAM
System library 2.0.6
Larry McVoy
: > So I'll make a little tool, maybe we can call the "linustool",
: > which lets him hack on the diffs and then applies them for him. But
: > what it really does is save away a copy of the diffs, get the
: > (possibly hacked) diffs from Linux when he says "apply", diff the
: > diffs, if they are changed, apply the first set as your changes,
: > and then apply the mods to that set as his change. It sounds
: > complicated and I'm sure it will be a little dicey, but I'm also
: > sure I can build that tool.
: Maybe I'm just super-dense or something, but...
:
: Q. Why is a tool like that needed? Surely one can simply produce a
: copy of the tree as it exists after one's own diff is applied,
: and a separate copy of the tree as released by Linus, and just
: diff one against the other? It's not exactly hard...
I must have done a crappy job explaining things because what you described
is exactly what won't work. If Linus has changed the patch you sent in,
then your diff will not show the files to be the same. Sure, it's true
that you can parse the diffs yourself and figure out that some of your
stuff got in - but the key point is that you, a human being, have to do
work.
I'm sure you are imaging that Linus will just changea thing or two and
it just isn't that big of a deal. But that isn't necessarily the case -
consider what happens if you submit a patch that changes a file that
other patches change as well. Your diff approach starts to get harder
and you - the human - have to do the extra work.
In the model that BitKeeper uses, you don't have to do any work - you
can detect in a program - without any chance whatsoever of getting an
incorrect result - if your changes have gone in or not. Regardless of
how many other patches went in to the same file, or the same line of the
same file, etc., etc.
Think about the complaints of the some of the developers who have had to
submit their patches over and over before Linus had time to apply them.
With BitKeeper, that patch process can become automatic - each time a new
release comes out, you run a tool over your tree and it checks against
the new release and resubmits the patch if it isn't in the new release.
Gabriel Paubert
On Thu, 26 Nov 1998, Brandon S. Allbery KF8NH wrote:
> In message <Pine.LNX.4.05.981125...@tahallah.demon.co.uk>,
> Ale
> x Buell writes:
> +-----
> | On Wed, 25 Nov 1998, Brandon S. Allbery KF8NH wrote:
> | > Linuxers, marred only by small issues such as (IIRC) ATI and S3 video
> | > cards vs. COM4. And it's right smack in the middle of the list of
> |
> | Ah yeah, the infamous COM4 bug with S3 chipsets. Seems some fuckwit used
> | the usual COM4 I/O port as one of its I/O registers. Ahh, that particular
> | chipset designer should have been taken out and made to use Microsoft
> | products in eternity (with a Windows 95 Beta!).
> +--->8
>
> Not exactly.
>
> The ATI and S3 chipsets started out as enhancements of IBM's 8514/A video
> card. But the 8514/A was designed for Microchannel, which addresses the
> entire I/O space. So the 8514/A used several registers with addresses
> 0xX2e8, for several values of X.
>
> The ISA bus only has 10 I/O address lines, so I/O addresses above 0x03FF
> effectively wrap around. The 8514/A ports ended up aliased to 0x02e8....
Even the first ISA bus had 20 address lines (although x86 I/O instructions
use only 16). Probably the reason to decode only 10 bits was rather that
the address decoder could be implemented in a simple 16 or 20 pin DIL chip
(PAL or whatever) on what was then an expansion board, because at the time
anything with more than 20 pins was huge and expensive.
[I have just checked the schematics, in the IBM Technical Reference,
Copyright 1981, Revised Januray 1983 that I've found: all address
pins are demultiplexed simultaneously from the 8088 and sent directly
to the ISA bus. All 20 bits are simultaneously valid.]
Gabriel.
Brandon S. Allbery KF8NH
x Buell writes:
+-----
| > The ISA bus only has 10 I/O address lines, so I/O addresses above 0x03FF
| > effectively wrap around. The 8514/A ports ended up aliased to 0x02e8....
|
| doesn't provide the address decoding stuff I think, it's down to the ISA
| card to do it, I believe.
True; but there are only 10 I/O address lines available in the ISA bus, so
there's no way to address above 0x03FF no matter how smart the card is.
Microchannel, EISA, and PCI support all 16 I/O address lines.
--
brandon s. allbery [os/2][linux][solaris][japh] all...@kf8nh.apk.net
system administrator [WAY too many hats] all...@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
Kiss my bits, Billy-boy.
-
Brandon S. Allbery KF8NH
+-----
| Or the engineer at IBM who decided that only decoding the low 10 bits
| for i/o port accesses was enough for all future.
The 8086/8088 only had 10 bits of I/O addressing, IIRC. The limitation on
80286+ was probably intended to avoid aliasing problems with 8-bit cards.
Brandon S. Allbery KF8NH
Pa
ubert writes:
+-----
| Even the first ISA bus had 20 address lines (although x86 I/O instructions
| use only 16). Probably the reason to decode only 10 bits was rather that
| the address decoder could be implemented in a simple 16 or 20 pin DIL chip
| (PAL or whatever) on what was then an expansion board, because at the time
| anything with more than 20 pins was huge and expensive.
Interesting. The reference I've been using only shows 10; but then, it's
hardly an official reference, and the source needs to be considered as well
(something put out by Compute! magazine back in the mid 1980s). I already
know the bloody thing was inaccurate about a number of other technical
details.
Alex Buell
> | port cards that has the broken 10bit address decoding circuitry. ISA buses
> | doesn't provide the address decoding stuff I think, it's down to the ISA
> | card to do it, I believe.
>
> True; but there are only 10 I/O address lines available in the ISA bus, so
> there's no way to address above 0x03FF no matter how smart the card is.
I thought the maximum was 20. After all, there are _some_ ISA cards that
can address up to 16MB of memory, aren't there? Perhaps you're talking of
the old 8bit ISA bus?
> Microchannel, EISA, and PCI support all 16 I/O address lines.
Hmm, yeah. At least, Intel did manage to come up with a really nice bus in
the guise of PCI, and what's more, it can be expanded to 64bit in the
future.
Cheers,
Alex
--
/\_/\ Legalise cannabis now!
( o.o ) Grow some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.
http://www.tahallah.demon.co.uk - *new* - rewritten for text browser users!
Linux tahallah 2.1.129 #63 SMP Sat Nov 21 23:52:03 EST 1998
Two Intel Pentium Pro 166MHz processors, 331.78 total bogomips, 48M RAM
System library 2.0.104
Gabriel Paubert
On Thu, 26 Nov 1998, Brandon S. Allbery KF8NH wrote:
> In message <Pine.HPP.3.96.98112...@gra-ux1.iram.es>, Gabriel
> Pa
> ubert writes:
> +-----
> | Even the first ISA bus had 20 address lines (although x86 I/O instructions
> | use only 16). Probably the reason to decode only 10 bits was rather that
> | the address decoder could be implemented in a simple 16 or 20 pin DIL chip
> | (PAL or whatever) on what was then an expansion board, because at the time
> | anything with more than 20 pins was huge and expensive.
> +--->8
>
> Interesting. The reference I've been using only shows 10; but then, it's
> hardly an official reference, and the source needs to be considered as well
> (something put out by Compute! magazine back in the mid 1980s). I already
> know the bloody thing was inaccurate about a number of other technical
> details.
No, all 20 bits were there (hint: the buffers that drive the ISA addresses
are directly on the processor address/bus, with another layer of buffers
on the MoBo taking these buffered signals to multiplex them into the DRAM
address pins).
And the ISA slots then could also be used to expand main memory with huge
boards holding as much as 256kB of DRAM ! What's interesting too is the
DRAM characteristic: 16 kbit chips with 250 nS access time and 410 nS
cycle time. DRAM capacities have increased tremendously (fortunately for
some companies who bloat SW for the sake of bloating it), improvements in
access/cycle times have been very relatively very slow.
However, even the decoder for onboard peripherals (DMA/Timer/8259/...)
"conveniently" forgets to decode more than 10 bits. Could have been done
cleanly with a single additional TTL chip...
Gabriel.
Gabriel Paubert
On Thu, 26 Nov 1998, Alex Buell wrote:
> I thought the maximum was 20. After all, there are _some_ ISA cards that
> can address up to 16MB of memory, aren't there? Perhaps you're talking of
> the old 8bit ISA bus?
Let us clear some confusion here: the term ISA is most often used to refer
to the AT expansion bus, 24 address and 16 data lines, using 2 connectors.
This bus is a superset of the original PC/XT bus, which has 20 address and
8 data lines, using a single connector. At some time in the past, MoBo
were differentiated by the number of 16 bit slots (AT) and 8 bit (XT)
ones.
>
> > Microchannel, EISA, and PCI support all 16 I/O address lines.
>
But often the Super-I/O chip (Serial/parallel...) only decodes 10 or 11
bits, 11 because some additional register for new parallel port modes
"unaliases" one bit to allow additional registers. The subtractive
decoding (last chance decoding or "if nobody volunteers to claim this PCI
cycle, I'll give it a try but I don't promise anything") of the ISA bridge
does the trick.
> Hmm, yeah. At least, Intel did manage to come up with a really nice bus in
> the guise of PCI, and what's more, it can be expanded to 64bit in the
> future.
Don't get me started on PCI. It has its own problems and is not "really
nice".
Gert Doering
>BTW, was anyone else somewhat shocked to discover that apparently nobody has
>a copy of what was then described by some as the "first really usable Linux
>kernel", namely 0.99.14? I may go rooting through my ancient backup tapes
>(if they haven't succombed to bitrot) over the weekend and see if I have an
>0.99.14 tree around still.
Looked into my archives, found neat stuff (names mangled to fit into 8+3
CDrom format):
-r-xr-xr-x 1 root other 740009 Jun 10 1993 lx09910.tgz
-r-xr-xr-x 1 root other 793633 Jul 27 1993 lx09911.tgz
-r-xr-xr-x 1 root other 862003 Sep 20 1993 lx09912.tgz
-r-xr-xr-x 1 root other 875591 Sep 24 1993 lx09913.tgz
-r-xr-xr-x 1 root other 1106588 Nov 29 1993 lx09914.tgz
-r-xr-xr-x 1 root other 1222118 Jan 29 1994 lx09914x.tgz
where shall I upload what?
gert
--
ge...@greenie.muc.de fax: +49-89-35655025 http://alpha.greenie.net/mgetty/
Mom's Law:
When they finally do have to take you to the hospital,
your underwear won't be clean or new.
Matthias Urlichs
>
> I've been looking into setting up a CVS tree that will contain the
> full kernel source history...
>
I have a PRCS tree which starts with 1.0.
I probably could add a "historic" subtree with pre-1.0 kernels...
... as soon as somebody has a _really_ complete kernel source archive.
--
Matthias Urlichs | noris network GmbH | sm...@noris.de | ICQ: 20193661
Matthias Urlichs
>
> Root of tree: nothing
> Branch for each major revision development kernel
> (eg -- 2.1.0 is represented as a diff from 2.0.0, but 2.0.0 is a
> diff from 1.3.99)
Nonono -- you want to check the linear history from 1.0 to 2.1.130 into
your CVS tree and let all the "dead end" production releases branch off of
that at the exact points they belong.
The simple reason is that the underlying RCS archiver does a lousy job
(i.e., accessing the current kernel gets awfully slow) if you do anything
else.
I've been using PRCS for my kernel tree, and RCS generates really _stupid_
revision numbers for the underlying files if you do not do this.
My diff for 2.1.130-pre3 => 2.1.130 starts like this:
--- dev.133/init/main.c Wed, 25 Nov 1998 13:16:13 +0100 smurf (kernel_linux/i/25_main.c 1.90.1.39.1.6.1.1.1.1.1.2.1.1.1.1.1.1.1.1.1.4.1.1.1.2.1.2.1.1.1.2.1.1.1.1.1.2.3.1.1.4.1.3.1.5.1.2.1.1.1.5.1.1.1.1 644)
+++ dev.134/init/main.c Fri, 27 Nov 1998 08:15:16 +0100 smurf (kernel_linux/i/25_main.c 1.90.1.39.1.6.1.1.1.1.1.2.1.1.1.1.1.1.1.1.1.4.1.1.1.2.1.2.1.1.1.2.1.1.1.1.1.2.3.1.1.4.1.3.1.5.1.2.1.1.1.5.1.1.1.2 644)
[...]
Anyway, any revision control system uses something like a revision tree,
and the only big problem is inserting something you've forgotten between
two existing revisions. But since 2.1.xx branched off of 2.0.21, "inserting"
a 2.0.37 is no problem at all.
Matthias Urlichs
> > >
> > > say we have 1.1.1, 1.1.3, 1.1.4
> > > put them in cvs and all of a sudden 1.1.2 appears from some kindly soul
> > > can cvs/rcs/sccs (you choose) handle this?
> >
> > That's why we have tags.
OK, but 1.1.2 would then have to be stored in a branch off of 1.1.2, where
it doesn't really belong.
But in practice that's not a problem.
> but in the above example, 1-1-2 would be stored as a diff relative to 1-1-4,
Wrong. The RCS file format is somewhat stupid, but it's not _that_ stupid.
It _does_ understand branches.
Daniel Engstrom
> In message <1998112613...@www.lillfab.se>, Daniel Engstrom writes:
> +-----
> | Or the engineer at IBM who decided that only decoding the low 10 bits
> | for i/o port accesses was enough for all future.
> +--->8
>
> The 8086/8088 only had 10 bits of I/O addressing, IIRC. The limitation on
> 80286+ was probably intended to avoid aliasing problems with 8-bit cards.
(Not that they saved that much, they could just have ORed together the
6 high address lines with AEN to make an IOAEN signal on the ISA bus.)
/Daniel
--
Harald Koenig
> In message <Pine.LNX.4.05.981125...@tahallah.demon.co.uk>,
> Ale
> x Buell writes:
> +-----
> | On Wed, 25 Nov 1998, Brandon S. Allbery KF8NH wrote:
> | > Linuxers, marred only by small issues such as (IIRC) ATI and S3 video
> | > cards vs. COM4. And it's right smack in the middle of the list of
> |
> | Ah yeah, the infamous COM4 bug with S3 chipsets. Seems some fuckwit used
> | the usual COM4 I/O port as one of its I/O registers. Ahh, that particular
> | chipset designer should have been taken out and made to use Microsoft
> | products in eternity (with a Windows 95 Beta!).
> +--->8
>
> Not exactly.
>
> The ATI and S3 chipsets started out as enhancements of IBM's 8514/A video
> card. But the 8514/A was designed for Microchannel, which addresses the
> entire I/O space. So the 8514/A used several registers with addresses
> 0xX2e8, for several values of X.
>
> The ISA bus only has 10 I/O address lines, so I/O addresses above 0x03FF
> effectively wrap around. The 8514/A ports ended up aliased to 0x02e8....
nope! the ISA bus has _16_ I/O address lines. but there are some (broken!)
serial cards around which only decode 10 address bits and thus cause
address aliases/ghosts and collisions...
> Arguably the bad design decision was to base an ISA card on the 8514/A. It
> couldn't be IBM's decision because (a) there was no wraparound on
> Microchannel and (b) Microchannel is perfectly capable of sharing IRQs, so
> COM4 could be on IRQ3 as originally documented without conflicting with COM2
> (and (c) they never intended 8514/A for use on ISA systems).
it _is_ IBM who made this broken decission! check the schematics in
IBM PC/XT technical handbook for their serial card (`async. communication adapt.'):
they're using a single 74LS30 (8port NAND) to decode AEN and A3...A9
adresses -- A10 to A15 aren't touched at all:(
Harald
--
All SCSI disks will from now on ___ _____
be required to send an email notice 0--,| /OOOOOOO\
24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\
\ \/OOOOOOOOOOOOOOO\
\ OOOOOOOOOOOOOOOOO|//
Harald Koenig, \/\/\/\/\/\/\/\/\/
Inst.f.Theoret.Astrophysik // / \\ \
koe...@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^
Harald Koenig
> On 25 Nov, Alex Buell wrote:
> > Ah yeah, the infamous COM4 bug with S3 chipsets.
> Actually it had precedence: some IBM video board (8514/A??) used that
> very address first.
>
> > Seems some fuckwit used the usual COM4 I/O port as one of its I/O
> > registers.
> It wasn't the COM4 address but something like 0xBE8 with the low 10 bits
> identical to 0x3E8, which is the COM4 base port. You'll need an
> el-cheapo serial board with 10-bit address decode only to be bitten by
> this.
please don't add confusion with wrong numbers:
IBM8514/A (and thus S3/ATI) uses 0x[4-b][26ae]e8 addresses which all will give
0x2E8 when cut off to 10 bits resulting in collision with COM4 !
0x3E8 is COM3...
> > Ahh, that particular chipset designer should have been taken out and made to use Microsoft
> > products in eternity (with a Windows 95 Beta!).
> Or the engineer at IBM who decided that only decoding the low 10 bits
> for i/o port accesses was enough for all future.
yep:(
or maybe it's the account manager who decided that there is no more money
for additional 6+ NAND inputs and thus one more chip on the board ?!
Johnny Tevessen
> Interesting. The reference I've been using only shows 10; but then, it's
> hardly an official reference, and the source needs to be considered as well
> (something put out by Compute! magazine back in the mid 1980s). I already
> know the bloody thing was inaccurate about a number of other technical
> details.
I just read an article in the latest c't (German computer magazine) which
included a part of a c't article about EISA slots of 04-92 with a top view
of the slot. It says: "This illustration corrects those printed in c't 12-89,
DOS intl 01-92, and Computer Persönlich 06-92." (which were two other
magazines totally unrelated with the first one.)
So never ever trust a specification from a single source, maybe not even
from three.
ciao,
johnny
--
Trust no-one.
Johnny Tevessen
> > Don't experiment with kernels on your HDs. Use floppy but
> > don't try to mount partitions.
>
> Especially since Linux 1.0 (and early) dislike IDE drives > 512Mb :-))
No problem. Some people (like me :) were smart enough to collect
a bunch of 300er Seagates. History lives!
Guest section DW
> # unix5
> Boot unix with @unix; login as root.
Where? Where can I get this one?
Pavel
ftp://ftp.digital.com/pub/DEC/sim/sources/
Andries
Riley Williams
>> What I'd like to see is some of the early releases of Linux, just
>> out of curiosity. Problem is, they all appear to be long since
>> filed in the old circular file...
> How old? The kernels, back to 1.0 are available on some ftp sites.
> tsx-11.mit.edu has v1.0, v1.2.xx as well as current kernels.
I've now analysed and listed all the kernel tarballs I can find, and
put the results on my website - a link can be found from...
...pointing to it. However, in summary...
1. There is a tarball for the 0.99.1 kernel release on the SunSite
UK mirror of ftp.kernel.org where, although the compression can
be removed, the resulting tarball is corrupt and unusable.
I would presume this to also relate to the copy on ftp.kernel.org
that it's mirrored from, but can't get onto that site as it's
too busy at the moment...
2. Kernels between 0.02 and 0.09 appear not to have survived. This
gap covers a period of some three months in the kernel's history.
3. There appear to be no surviving tarballs of any of the 0.98
releases, or of most of the 0.99 releases. This gap covers a
period of some 10 months in the kernel's history.
4. Many of the 1.1 series kernels appear not to have survived,
judging by the release numbers that exist. However, it appears
that development was particularly fast at this stage, as it is
not unusual for ten patchlevels to appear within a week.
5. With the exception of kernel 1.3.1, all of the 1.2 and later
kernels appear to be available.
Comments?
If you can locate any missing tarballs, please send me the URL where I
can lay my hands on them, and I'll add them to the list...
Best wishes from Riley.
Riley Williams
> Have you tried
> ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/old-versions/
> as it contains several patches and tar balls in 0.95-0.99 range. I
> tried linux-0.99.1.tar.gz and it gunzips and seems to be ok.
I've now stripped everything off there and added it to my list, with
bzip2'd versions of the stuff not on SunSite-UK made available from my
own FTP site. For reference, the URL is in my signature below.
> Also, in /pub/Linux/PEOPLE/Linus/v1.1 there are no tarballs for
> 1.1.1 (only 1.1.13), but patch[1-9].gz and patch1[0-3].gz exist.
If I create the patches myself, they don't have the original release
timestamps, which is what I'm interested in...
Best wishes from Riley.
---
* http://www.amush.ml.org/~rhw/kernel.versions.html
Riley Williams
>> But we don't. 0.99.14, for example, is noticeably missing from
>> the list --- and I remember 0.99.14 very well because it was the
>> first kernel that was stable enough for production use by most
>> then Linuxers, marred only by small issues such as (IIRC) ATI and
>> S3 video cards vs. COM4. And it's right smack in the middle of the
>> list of released kernels.
> Ah yeah, the infamous COM4 bug with S3 chipsets. Seems some fuckwit
> used the usual COM4 I/O port as one of its I/O registers. Ahh, that
> particular chipset designer should have been taken out and made to
> use Microsoft products in eternity (with a Windows 95 Beta!).
I can't comment re the bug you mention since I've never experienced
it, but I can confirm that 0.99.14 (as well as the rest of the missing
0.99.* series) is now available from the kernel version history page
I've put up...
Riley Williams
> Does anyone actually know of any official Linux kernel releases
> missing from ftp.kernel.org? If so, could you just post a list of
> them so that people can look for them - if not, just make a CVS
> tree of all the releases to date (maybe waiting for 2.2.0 and
> putting that as the last entry), make a CD image and be happy.
There's actually quite a few missing from it, as well as one that's
corrupted. All the ones that I've tracked down are listed in the
kernel version index I've put online at the URL below, and those I've
come across that aren't on the SunSite-UK mirror of ftp.kernel.org
(plus the one on there that's corrupted, I found an uncorrupted copy
thereof), along with bzip2'd versions of the ones not bzip2'd on
SunSite's UK mirror, can be found at...
ftp://ftp.amush.ml.org/pub/rhw/Linux/
All have been timestamped with the most recent timestamp contained
therein...and if you wish to move them to ftp.kernel.org you have my
blessings...
Best wishes from Riley.
Matthew G. Marsh
[snip]
> There's actually quite a few missing from it, as well as one that's
> corrupted. All the ones that I've tracked down are listed in the
> kernel version index I've put online at the URL below, and those I've
> come across that aren't on the SunSite-UK mirror of ftp.kernel.org
> (plus the one on there that's corrupted, I found an uncorrupted copy
> thereof), along with bzip2'd versions of the ones not bzip2'd on
> SunSite's UK mirror, can be found at...
>
> ftp://ftp.amush.ml.org/pub/rhw/Linux/
>
> All have been timestamped with the most recent timestamp contained
> therein...and if you wish to move them to ftp.kernel.org you have my
> blessings...
>
> Best wishes from Riley.
Thanks for the central collection!! - I was trying to do that myself -
however I am going to mirror your collection instead. (If you don't
mind..)
It should be available at:
http://www.linuxgrill.com/kernel/
Thanks again!!
--------------------------------------------------
Matthew G. Marsh, President
Paktronix Systems LLC
1506 North 59th Street
Omaha NE 68104
Phone: (402) 932-7250
Email: m...@paktronix.com
WWW: http://www.paktronix.com
--------------------------------------------------
Matthew G. Marsh
[snip]
> There's actually quite a few missing from it, as well as one that's
> corrupted. All the ones that I've tracked down are listed in the
> kernel version index I've put online at the URL below, and those I've
> come across that aren't on the SunSite-UK mirror of ftp.kernel.org
> (plus the one on there that's corrupted, I found an uncorrupted copy
> thereof), along with bzip2'd versions of the ones not bzip2'd on
> SunSite's UK mirror, can be found at...
>
> ftp://ftp.amush.ml.org/pub/rhw/Linux/
>
> All have been timestamped with the most recent timestamp contained
> therein...and if you wish to move them to ftp.kernel.org you have my
> blessings...
Well - I have a mirror of this directory and the mirror of ftp.kernel.org
and the mirror of ftp.win.tue.nl all in the same place. Please feel free
to check it out (it only does HTTP downloads at the moment - if you would
like ftp access let me know and I will setup access)
Thanks to all - please let me know if I have any corrupted items
(especially the one you mentioned above...)
> Best wishes from Riley.
Thanks again and here is the URL:
http://www.linuxgrill.com/kernel/
Riley Williams
> Looked into my archives, found neat stuff (names mangled to fit
> into 8+3 CDrom format):
> -r-xr-xr-x 1 root other 740009 Jun 10 1993 lx09910.tgz
> -r-xr-xr-x 1 root other 793633 Jul 27 1993 lx09911.tgz
> -r-xr-xr-x 1 root other 862003 Sep 20 1993 lx09912.tgz
> -r-xr-xr-x 1 root other 875591 Sep 24 1993 lx09913.tgz
> -r-xr-xr-x 1 root other 1106588 Nov 29 1993 lx09914.tgz
> -r-xr-xr-x 1 root other 1222118 Jan 29 1994 lx09914x.tgz
> where shall I upload what?
I'm not sure what the last one is, but I already have all the rest
referenced on my webpage...
Have a look at it, and if it's not there, email it to me please...
Best wishes from Riley.
Riley Williams
>> There's actually quite a few missing from it, as well as one that's
>> corrupted. All the ones that I've tracked down are listed in the
>> kernel version index I've put online at the URL below, and those I've
>> come across that aren't on the SunSite-UK mirror of ftp.kernel.org
>> (plus the one on there that's corrupted, I found an uncorrupted copy
>> thereof), along with bzip2'd versions of the ones not bzip2'd on
>> SunSite's UK mirror, can be found at...
>>
>> ftp://ftp.amush.ml.org/pub/rhw/Linux/
>>
>> All have been timestamped with the most recent timestamp contained
>> therein...and if you wish to move them to ftp.kernel.org you have my
>> blessings...
> Thanks for the central collection!! - I was trying to do that myself -
> however I am going to mirror your collection instead. (If you don't
> mind..)
I don't mind in the slightest...
> It should be available at:
>
> http://www.linuxgrill.com/kernel/
>
> Thanks again!!
Nae problem...
Michael Stiller
> 4. Many of the 1.1 series kernels appear not to have survived,
> judging by the release numbers that exist. However, it appears
> that development was particularly fast at this stage, as it is
> not unusual for ten patchlevels to appear within a week.
>
> 5. With the exception of kernel 1.3.1, all of the 1.2 and later
> kernels appear to be available.
>
> Comments?
I've an old linux distribution cd which includes a sunsite.unc.edu mirror.
I include a ls v*:
[536]toyland:$ ls v*
v1.0:
TRANS.TBL patch2.gz patch4.gz patch6.gz patch8.gz
patch1.gz patch3.gz patch5.gz patch7.gz patch9.gz
v1.1:
1.0.6-1.1.0.diff.gz changes69 patch46.gz
LATEST-IS-1.1.95 changes70 patch47.gz
TRANS.TBL changes71 patch48.gz
bdflush-1.5.tar.gz changes72 patch49.gz
changes14 changes73 patch5.gz
changes15 changes74 patch50.gz
changes16 changes75 patch51.gz
changes17 changes76 patch52.gz
changes18 changes77 patch53.gz
changes19 changes78 patch54.gz
changes20 changes79 patch55.gz
changes21 changes80 patch56.gz
changes22 changes81 patch57.gz
changes23 linux-1.1.23.tar.gz patch58.gz
changes24 linux-1.1.63.tar.gz patch59.gz
changes25 linux-1.1.85.tar.gz patch6.gz
changes26 modules-1.1.67.tar.gz patch60.gz
changes27 modules-1.1.87.tar.gz patch61.gz
changes28 patch1.gz patch62.gz
changes29 patch10.gz patch63.gz
changes30 patch11.gz patch64.gz
changes31 patch12.gz patch65.gz
changes32 patch13.gz patch66.gz
changes33 patch14.gz patch67.gz
changes34 patch15.gz patch68.gz
changes35 patch16.gz patch69.gz
changes36 patch17.gz patch7.gz
changes37 patch18.gz patch70.gz
changes38 patch19.gz patch71.gz
changes39 patch2.gz patch72.gz
changes40 patch20.gz patch73.gz
changes41 patch21.gz patch74.gz
changes42 patch22.gz patch75.gz
changes43 patch23.gz patch76.gz
changes44 patch24.gz patch77.gz
changes45 patch25.gz patch78.gz
changes46 patch26.gz patch79.gz
changes47 patch27.gz patch8.gz
changes48 patch28.gz patch80.gz
changes49 patch29.gz patch81.gz
changes50 patch3.gz patch82.gz
changes51 patch30.gz patch83.gz
changes52 patch31.gz patch84.gz
changes53 patch32.gz patch85.gz
changes54 patch33.gz patch86.gz
changes55 patch34.gz patch87.gz
changes56 patch35.gz patch88.gz
changes57 patch36.gz patch89.gz
changes58 patch37.gz patch9.gz
changes59 patch38.gz patch90.gz
changes60 patch39.gz patch91.gz
changes61 patch4.gz patch92.gz
changes62 patch40.gz patch93.gz
changes63 patch41.gz patch94.gz
changes64 patch42.gz patch95.gz
changes66 patch43.gz v1.1.0.tar.gz
changes67 patch44.gz
changes68 patch45.gz
v1.2:
LATEST-IS-1.2.11 patch-1.2.1.gz patch-1.2.5.gz
TRANS.TBL patch-1.2.10.gz patch-1.2.6.gz
bdflush-1.5.tar.gz patch-1.2.11.gz patch-1.2.7.gz
linux-1.2.0.tar.gz patch-1.2.2.gz patch-1.2.8.gz
linux-1.2.11.tar.gz patch-1.2.3.gz patch-1.2.9.gz
modules-1.2.8.tar.gz patch-1.2.4.gz v1.1.95-1.2.0.patch.gz
v1.3:
LATEST-IS-1.3.8 linux-1.3.8.tar.gz patch-1.3.3.gz patch-1.3.6.gz
TRANS.TBL patch-1.3.1.gz patch-1.3.4.gz patch-1.3.7.gz
linux-1.3.0.tar.gz patch-1.3.2.gz patch-1.3.5.gz patch-1.3.8.gz
It should be possible to create tarballs from this patches.
I can put this on ftp or http server if someone is interested.
-Michael
Mark H. Wood
> it _is_ IBM who made this broken decission! check the schematics in
> IBM PC/XT technical handbook for their serial card (`async. communication adapt.'):
> they're using a single 74LS30 (8port NAND) to decode AEN and A3...A9
> adresses -- A10 to A15 aren't touched at all:(
Makes perfect sense. Remember that the PC came out of IBM's Entry Systems
Division. So you'd get used to buying IBM with a really cheap machine (in
both senses) and then, when you outgrew it, they'd move you up to a System
3x or whatever.
--
Mark H. Wood, Lead System Programmer mw...@IUPUI.Edu
Innovation is only valuable if it improves one's life; otherwise it's
just one more silly change to cope with.
Rik van Riel
> 4. Many of the 1.1 series kernels appear not to have survived,
> judging by the release numbers that exist. However, it appears
> that development was particularly fast at this stage, as it is
> not unusual for ten patchlevels to appear within a week.
>
> 5. With the exception of kernel 1.3.1, all of the 1.2 and later
> kernels appear to be available.
I've seen these kernels (all of 1.1 and 1.3.1) on an
Infomagic CDROM set. IIRC, of course.
Unfortunately I have given my old CDs away so I don't
have them any more :(
succes,
Rik -- now completely used to dvorak kbd layout...
+-------------------------------------------------------------------+
| Linux memory management tour guide. H.H.v...@phys.uu.nl |
| Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ |
+-------------------------------------------------------------------+
Thomas Molina
set from Sept 1996, about the time I got interested again. I have diffs
for the entire 1.2 and 1.3 series of kernels, including 1.3.1. If any
of these are of help, I can provide them to someone.
On Mon, 30 Nov 1998, Rik van Riel wrote:
> On Fri, 27 Nov 1998, Riley Williams wrote:
>
> > 4. Many of the 1.1 series kernels appear not to have survived,
> > judging by the release numbers that exist. However, it appears
> > that development was particularly fast at this stage, as it is
> > not unusual for ten patchlevels to appear within a week.
> >
> > 5. With the exception of kernel 1.3.1, all of the 1.2 and later
> > kernels appear to be available.
>
> I've seen these kernels (all of 1.1 and 1.3.1) on an
> Infomagic CDROM set. IIRC, of course.
>
> Unfortunately I have given my old CDs away so I don't
> have them any more :(
Steven Roberts
> +-----
> | I'm not sure what the problem is - I have no intent or interest in recreating
> | all the steps between releases, but we have all the released version of the
> | kernels. So what's to prevent from getting the first one, checking it in,
> +--->8
>
> But we don't. 0.99.14, for example, is noticeably missing from the list ---
> and I remember 0.99.14 very well because it was the first kernel that was
> stable enough for production use by most then Linuxers, marred only by small
> issues such as (IIRC) ATI and S3 video cards vs. COM4. And it's right smack
> in the middle of the list of released kernels.
>
it was the C++ kernel release...
was 0.99pl13 the C++ compiled one then? I remember Linus did it for one
and only rev...
just curious (memory a little foggy...)
Steve
Brandon S. Allbery KF8NH
+-----
| > But we don't. 0.99.14, for example, is noticeably missing from the list --
| it was the C++ kernel release...
|
| was 0.99pl13 the C++ compiled one then? I remember Linus did it for one
| and only rev...
I think C++ experimentation came later --- g++ was well known to be unusable
in the 0.99 days. IIRC it was somewhere in the 1.1 series (my memory
suggests one of the 1.1.4x, and that the attempt actually lasted through
three point releases, but my memory isn't the most trustworthy thing on the
planet :-) that it was attempted.
--
brandon s. allbery [os/2][linux][solaris][japh] all...@kf8nh.apk.net
system administrator [WAY too many hats] all...@ece.cmu.edu
carnegie mellon / electrical and computer engineering KF8NH
Kiss my bits, Billy-boy.
Stephen Harris
: I think C++ experimentation came later --- g++ was well known to be unusable
: in the 0.99 days. IIRC it was somewhere in the 1.1 series (my memory
A boring historical delve into early C++ kernels...
Looking back over my old CD collection, the Yggdrasil Linux Internet
Archive, May 1995, Disk 2 (Sunsite mirror) has a 0.99.11 kernel which
has in the Makefile....
#
# standard CFLAGS
#
CFLAGS = -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer -x c++
The 0.99.12 kernel README file reads...
NOTABLE changes since patchlevel 10 or earlier:
- The kernel is now compiled with C++ instead of plain C. Very few
actual C++ features are used, but even so C++ allows for more
type-checking and type-safe linkage.
A quick grep of the 0.99.11 tree doesn't actually show any comments on
this!
The 0.99.13 kernel Makefile has the c++ bit commented out...
CFLAGS = -Wall -Wstrict-prototypes -O6 -fomit-frame-pointer # -x c++
but this doesn't appear to be documented...
Annoyingly the CD misses the 0.99.14 kernel totally.... The Walnut Creek
"Toolkit for Linux" August 1994 jumps into the gap :-)
The 0.99.14 kernel has a CHANGES file and this reads (editted)
CHANGES since 0.99 patchlevel 12 and earlier:
- compiled with plain C by default instead of C++
<wavey lines>
When I put a production environment (running 0.99.12.small-patch) into
effect, I ignored the C++ option as too unstable :-) Heh, those ships
have over 100days uptimes (according to an ex-cow-orker who just visited
one of them!)
</wavey lines>
Hope this answers any questions :-)
--
Stephen Harris
sw...@spuddy.mew.co.uk http://www.spuddy.org/
The truth is the truth, and opinion just opinion. But what is what?
My employer pays to ignore my opinions; you get to do it for free.
* Meeeeow ! Call Spud the Cat on > 01268 515441 < for free Usenet access *
Aaron Tiensivu
The sad truth is that most of the Windows 95 betas were more stable than the
final version.
Believe it... or not.. :)
Alan Olsen
> Subject: Re: The history of the Linux OS
> > products in eternity (with a Windows 95 Beta!).
>
> The sad truth is that most of the Windows 95 betas were more stable than the
> final version.
As were the Win98 betas. (Sometimes I wonder if the later betas are for
testing the first set of patches to be released sometime after they get it out
the door.)
--
Alan Olsen