From: nani@td2cad.intel.com (V. Narayanan)
Newsgroups: comp.os.linux
Subject: Writing an OS - questions !!
Date: 5 May 92 01:57:05 GMT
Reply-To: nani@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: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
Newsgroups: comp.os.linux
Subject: Re: Writing an OS - questions !!
Date: 5 May 92 07:58:17 GMT
Organization: University of Helsinki
In article <10685@inews.intel.com> nani@td2cad.intel.com (V. Narayanan) writes:
>
>Hi folks,
> For quite some time this "novice" has been wondering as to how one goes
>about the task of writing an OS from "scratch". So here are some questions,
>and I would appreciate if you could take time to answer 'em.
Well, I see someone else already answered, but I thought I'd take on the
linux-specific parts. Just my personal experiences, and I don't know
how normal those are.
>1) How would you typically debug the kernel during the development phase?
Depends on both the machine and how far you have gotten on the kernel:
on more simple systems it's generally easier to set up. Here's what I
had to do on a 386 in protected mode.
The worst part is starting off: after you have even a minimal system you
can use printf etc, but moving to protected mode on a 386 isn't fun,
especially if you at first don't know the architecture very well. It's
distressingly easy to reboot the system at this stage: if the 386
notices something is wrong, it shuts down and reboots - you don't even
get a chance to see what's wrong.
Printf() isn't very useful - a reboot also clears the screen, and
anyway, you have to have access to video-mem, which might fail if your
segments are incorrect etc. Don't even think about debuggers: no
debugger I know of can follow a 386 into protected mode. A 386 emulator
might do the job, or some heavy hardware, but that isn't usually
feasible.
What I used was a simple killing-loop: I put in statements like
die:
jmp die
at strategic places. If it locked up, you were ok, if it rebooted, you
knew at least it happened before the die-loop. Alternatively, you might
use the sound io ports for some sound-clues, but as I had no experience
with PC hardware, I didn't even use that. I'm not saying this is the
only way: I didn't start off to write a kernel, I just wanted to explore
the 386 task-switching primitives etc, and that's how I started off (in
about April-91).
After you have a minimal system up and can use the screen for output, it
gets a bit easier, but that's when you have to enable interrupts. Bang,
instant reboot, and back to the old way. All in all, it took about 2
months for me to get all the 386 things pretty well sorted out so that I
no longer had to count on avoiding rebooting at once, and having the
basic things set up (paging, timer-interrupt and a simple task-switcher
to test out the segments etc).
>2) Can you test the kernel functionality by running it as a process on a
> different OS? Wouldn't the OS(the development environment) generate
> exceptions in cases when the kernel (of the new OS) tries to modify
> 'priviledged' registers?
Yes, it's generally possible for some things, but eg device drivers
usually have to be tested out on the bare machine. I used minix to
develop linux, so I had no access to IO registers, interrupts etc.
Under DOS it would have been possible to get access to all these, but
then you don't have 32-bit mode. Intel isn't that great - it would
probably have been much easier on a 68040 or similar.
So after getting a simple task-switcher (it switched between two
processes that printed AAAA... and BBBB... respectively by using the
timer-interrupt - Gods I was proud over that), I still had to continue
debugging basically by using printf. The first thing written was the
keyboard driver: that's the reason it's still written completely in
assembler (I didn't dare move to C yet - I was still debugging at
about instruction-level).
After that I wrote the serial drivers, and voila, I had a simple
terminal program running (well, not that simple actually). It was still
the same two processes (AAA..), but now they read and wrote to the
console/serial lines instead. I had to reboot to get out of it all, but
it was a simple kernel.
After that is was plain sailing: hairy coding still, but I had some
devices, and debugging was easier. I started using C at this stage, and
it certainly speeds up developement. This is also when I start to get
serious about my megalomaniac ideas to make "a better minix that minix".
I was hoping I'd be able to recompile gcc under linux some day...
The harddisk driver was more of the same: this time the problems with
bad documentation started to crop up. The PC may be the most used
architecture in the world right now, but that doesn't mean the docs are
any better: in fact I haven't seen /any/ book even mentioning the weird
386-387 coupling in an AT etc (Thanks Bruce).
After that, a small filesystem, and voila, you have a minimal unix. Two
months for basic setups, but then only slightly longer until I had a
disk-driver (seriously buggy, but it happened to work on my machine) and
a small filesystem. That was about when I made 0.01 available (late
august-91? Something like that): it wasn't pretty, it had no floppy
driver, and it couldn't do much anything. I don't think anybody ever
compiled that version. But by then I was hooked, and didn't want to
stop until I could chuck out minix.
>3) Would new linkers and loaders have to be written before you get a basic
> kernel running?
All versions up to about 0.11 were crosscompiled under minix386 - as
were the user programs. I got bash and gcc eventually working under
0.02, and while a race-condition in the buffer-cache code prevented me
from recompiling gcc with itself, I was able to tackle smaller compiles.
0.03 (October?) was able to recompile gcc under itself, and I think
that's the first version that anybody else actually used. Still no
floppies, but most of the basic things worked.
Afetr 0.03 I decided that the next version was actually useable (it was,
kind of, but boy is X under 0.96 more impressive), and I called the next
version 0.10 (November?). It still had a rather serious bug in the
buffer-cache handling code, but after patching that, it was pretty ok.
0.11 (December) had the first floppy driver, and was the point where I
started doing linux developement under itself. Quite as well, as I
trashed my minix386 partition by mistake when trying to autodial
/dev/hd2.
By that time others were actually using linux, and running out of
memory. Especially sad was the fact that gcc wouldn't work on a 2MB
machine, and although c386 was ported, it didn't do everything gcc did,
and couldn't recompile the kernel. So I had to implement disk-paging:
0.12 came out in January (?) and had paging by me as well as job control
by tytso (and other patches: pmacdona had started on VC's etc). It was
the first release that started to have "non-essential" features, and
being partly written by others. It was also the first release that
actually did many things better than minix, and by now people started to
really get interested.
Then it was 0.95 in March, bugfixes in April, and soon 0.96. It's
certainly been fun (and I trust will continue to be so) - reactions have
been mostly very positive, and you do learn a lot doing this type of
thing (on the other hand, your studies suffer in other respects :)
Linus