Linux History 101 :)

3 views
Skip to first unread message

Ragnar Hojland Espinosa

unread,
Nov 21, 1998, 3:00:00 AM11/21/98
to Linux Kernel

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

unread,
Nov 22, 1998, 3:00:00 AM11/22/98
to linux-...@vger.rutgers.edu
On Fri, Nov 20, 1998 at 07:48:45PM +0100, Ragnar Hojland Espinosa wrote:
>
> 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

unread,
Nov 22, 1998, 3:00:00 AM11/22/98
to Ragnar Hojland Espinosa
> 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!)

Paul

Simon Kenyon

unread,
Nov 22, 1998, 3:00:00 AM11/22/98
to linux-...@vger.rutgers.edu
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. 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

unread,
Nov 22, 1998, 3:00:00 AM11/22/98
to Simon Kenyon
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.

Simon Kenyon

unread,
Nov 22, 1998, 3:00:00 AM11/22/98
to Riley Williams
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

Riley Williams

unread,
Nov 22, 1998, 3:00:00 AM11/22/98
to Simon Kenyon
Hi Simon.

>> 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

unread,
Nov 22, 1998, 3:00:00 AM11/22/98
to Paul Wouters
On Sun, 22 Nov 1998, Paul Wouters wrote:

> > 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

unread,
Nov 22, 1998, 3:00:00 AM11/22/98
to Ragnar Hojland Espinosa
On Fri, 20 Nov 1998, Ragnar Hojland Espinosa wrote:

>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

unread,
Nov 22, 1998, 3:00:00 AM11/22/98
to Riley Williams

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

unread,
Nov 22, 1998, 3:00:00 AM11/22/98
to linux-...@vger.rutgers.edu
Followup to: <Pine.LNX.3.96.981122...@ps.cus.umist.ac.uk>
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:
>
> 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...
>

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.

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to Riley Williams
From: Riley Williams <r...@bigfoot.com>
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

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to
You might want to add this to your collection:
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

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to h...@transmeta.com
From: h...@transmeta.com (H. Peter Anvin)

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

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to Linux Kernel
Quoting Riley Williams (r...@bigfoot.com):

> 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

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to Johnny Tevessen
On 23-Nov-98 Johnny Tevessen wrote:
> 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

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to Johnny Tevessen
Hi Johnny.

>> 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

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to Simon Kenyon
Hi Simon.

>> 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

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to Riley Williams
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?
--
simon

Jim Gettys

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to Simon Kenyon

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

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to Riley Williams
On Mon, 23 Nov 1998, Riley Williams wrote:
> > 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...

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

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to Jim Gettys
On 23-Nov-98 Jim Gettys wrote:
> 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

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to Simon Kenyon
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.

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

unread,
Nov 23, 1998, 3:00:00 AM11/23/98
to Geert Uytterhoeven
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 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

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to Simon Kenyon
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 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

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to Geert Uytterhoeven
On 23-Nov-98 Geert Uytterhoeven wrote:
>> 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

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to Simon Kenyon
On Mon, 23 Nov 1998, Simon Kenyon wrote:
> On 23-Nov-98 Geert Uytterhoeven wrote:
> >> 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

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to Geert.Uyt...@cs.kuleuven.ac.be, r...@bigfoot.com
> CVS tree?

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

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to j...@pa.dec.com

> 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

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to linux-...@vger.rutgers.edu
Simon Kenyon <si...@koala.ie> asks:
: 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

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to Riley Williams
Date: Sun, 22 Nov 1998 16:50:50 +0000 (GMT)
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

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to dwg...@win.tue.nl
As Andries pointed out, the old kernels are actually fairly well
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

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to dwg...@win.tue.nl, ty...@mit.edu
Two hours ago or so I promised 1.0 and up.
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

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to linux-...@vger.rutgers.edu
In article <Pine.LNX.3.96.981123...@ps.cus.umist.ac.uk> you write:
> > 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

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to Linux Kernel
On Nov 23, Geert Uytterhoeven wrote:

> 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

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to Theodore Y Ts'o
Hi Ted.

> 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

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to Neil Conway
On Tue, 24 Nov 1998, Neil Conway wrote:
> 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 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.
>
> The real problem doesn't really go away though. Unless I miss my guess
> (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

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to Geert Uytterhoeven

Neil

Alex Buell

unread,
Nov 24, 1998, 3:00:00 AM11/24/98
to Guest section DW
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? :)

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

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to linux-...@vger.rutgers.edu
Quoting Hans-Joachim Baader (ha...@grumbeer.inka.de):

[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

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to an...@canuck.gen.nz, dwg...@win.tue.nl
From an...@canuck.gen.nz Tue Nov 24 15:33:19 1998
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

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to r...@bigfoot.com, ty...@mit.edu
From: Riley Williams <r...@bigfoot.com>

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

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to Brandon S. Allbery KF8NH
: In message <1998112323...@bitmover.com>, Larry McVoy writes:
: +-----
: | 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.

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

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to Larry McVoy
In message <1998112323...@bitmover.com>, Larry McVoy writes:
+-----
| 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

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to linux-...@vger.rutgers.edu
In message <XFMail.98112...@koala.ie>, Simon Kenyon writes:
+-----

| On 23-Nov-98 Geert Uytterhoeven wrote:
| > 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 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
+--->8

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

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to Larry McVoy
In message <1998112503...@bitmover.com>, Larry McVoy writes:
+-----
| 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
+--->8

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

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to Alex Buell
On Tue, 24 Nov 1998, Alex Buell wrote:
> 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

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to Brandon S. Allbery KF8NH
: 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.

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

unread,
Nov 25, 1998, 3:00:00 AM11/25/98
to Neil Conway

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

unread,
Nov 26, 1998, 3:00:00 AM11/26/98
to Riley Williams, linux-...@vger.rutgers.edu
On 22 Nov 98, at 13:45, 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.

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

unread,
Nov 26, 1998, 3:00:00 AM11/26/98
to Geert Uytterhoeven
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.

Ciao,
Riccardo.

Brandon S. Allbery KF8NH

unread,
Nov 26, 1998, 3:00:00 AM11/26/98
to Larry McVoy
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.

--
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

unread,
Nov 26, 1998, 3:00:00 AM11/26/98
to Larry McVoy
Hi Larry.

> 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

unread,
Nov 26, 1998, 3:00:00 AM11/26/98
to Greaves Tristan TM
In message <45ACD3A39598D111BD09...@cluster1.tsc.icl.co.uk>
, G
reaves Tristan TM writes:
+-----

| > trees. So we can't use it until we've found *all* the kernel revisions.
|
| 1. Populate the tree with all the Linux kernel versions you have. In
| 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

unread,
Nov 26, 1998, 3:00:00 AM11/26/98