Suggestions for new FAQ entries
Posted: Sat May 18, 2002 11:00 pm
I don't know if Dark Fiber or any of the others
who maintain the various OS development FAQs
frequent this forum, but I do have some FAQ
answers I thought I'd recommend.
Q: What does an OS have to have/do?
A: There is no straightforward answer to this
question; ultimately, you as the OS developer
will have to decide what you want it to do.
However, there are some things which are common
to most if not all operating systems on the PC
platform. A reasonable, if somewhat debatable,
list of these minimal actions and features would
be:
- It must start itself up. (This does not
necessarily mean it should boot cold; it is
probably wiser to use a nootloader such as GRUB
to handle the initial stages).
- it must initialize the interrupt vector table,
and recover from system exceptions if possible.
- it must be able to write to the display and
read from the keyboard, or else provide some
other kind of basic user interaction.
- it must be able to identify disk types and read
from and write to a disk at a low level (at least
a floppy disk; hard disk may be put of until
later).
- it must be able to accuratetly work with the disk format it uses (for example, in the case a
FAT12/16/32 disk it should be able to read the
FATs; allocate disk space for a new file, add a
new file entry in the FATs and save the file to
the allocated space; read a file or part of one
into memory; modify an existing file and its FAT
entry to match the changes; delete a file entry).
- it must be able to start up utilities and
applications of some sort (don't forget that in
single-tasking systems, it also has to return
control to the system when the app finishes).
- It should handle allocation of resources
(memory and disk space probably being the most
crucial), and handle deallocating and
reallocating them when they are released.
- It must provide some mechanism for applications
to access system resources and functions,
preferably (though there is some argument on this
point) at a higher level of abstraction, to make
writing application software easier.
While there are many other features that others
would argue are as important, these are the ones
which are pretty much absolute rock-bottom least
that an OS should have.
---------------------
Q: Should I use the BIOS for low-level
programming, or write my own disk drivers, etc.
A: The answer depends on a number of factors.
First off, the answer most OS designers would
give to using BIOS calls in protected mode is a
resounding *NO*! The standard BIOS software is
all 16-bit real mode code; the work needed to
access it from p-mode (initializing a v86 taks,
jumping to and from p-mode and v86 mode for even
the simplest I/O, etc.) is far more work than
writing your own p-mode drivers. While this has
been a matter of some controversy, it is
generally agreed that using the BIOS in p-mode is
very unwise.
The choice is less clear for a real mode OS.
While using the BIOS can save a great deal of
hassle, and is familiar to the many DOS
programmers already, it has several drawbacks.
BIOS routines are generally considerably slower
than your own code would be; more seriously, BIOS
routines are designed around polling, not
interrupts, and are consequently inherently
inefficient in a multitasking system, and even in
a single-tasking OS use more time and space than
they should as a result. Even DOS rewrote many if
not most of the low-level functions in it's later
incarnations. Writing one's own drivers, while
often a great deal of work, can still be well
worth the effort.
Q: Should I write my own bootstrap?
A: The general concensus is that, while it is a good idea to experiment with writing *a*
bootstrap loader in order to better undertand the
boot process, most OS writers would be far better
served using an existing boot loader like GRUB
for their actual OSes. The boot process is
extremely hairy, and can a suitable one has to
handle a great many different hardware
configurations. Too many OS projects have sank on
those shoals; it is far better to put your effort
into writing your kernel and memory manager than
waste a lot of effort on something that should be
at most a few seconds of your system's running
time.
I'm out of time, but I'll have more soon. Any
comments or corrections?
who maintain the various OS development FAQs
frequent this forum, but I do have some FAQ
answers I thought I'd recommend.
Q: What does an OS have to have/do?
A: There is no straightforward answer to this
question; ultimately, you as the OS developer
will have to decide what you want it to do.
However, there are some things which are common
to most if not all operating systems on the PC
platform. A reasonable, if somewhat debatable,
list of these minimal actions and features would
be:
- It must start itself up. (This does not
necessarily mean it should boot cold; it is
probably wiser to use a nootloader such as GRUB
to handle the initial stages).
- it must initialize the interrupt vector table,
and recover from system exceptions if possible.
- it must be able to write to the display and
read from the keyboard, or else provide some
other kind of basic user interaction.
- it must be able to identify disk types and read
from and write to a disk at a low level (at least
a floppy disk; hard disk may be put of until
later).
- it must be able to accuratetly work with the disk format it uses (for example, in the case a
FAT12/16/32 disk it should be able to read the
FATs; allocate disk space for a new file, add a
new file entry in the FATs and save the file to
the allocated space; read a file or part of one
into memory; modify an existing file and its FAT
entry to match the changes; delete a file entry).
- it must be able to start up utilities and
applications of some sort (don't forget that in
single-tasking systems, it also has to return
control to the system when the app finishes).
- It should handle allocation of resources
(memory and disk space probably being the most
crucial), and handle deallocating and
reallocating them when they are released.
- It must provide some mechanism for applications
to access system resources and functions,
preferably (though there is some argument on this
point) at a higher level of abstraction, to make
writing application software easier.
While there are many other features that others
would argue are as important, these are the ones
which are pretty much absolute rock-bottom least
that an OS should have.
---------------------
Q: Should I use the BIOS for low-level
programming, or write my own disk drivers, etc.
A: The answer depends on a number of factors.
First off, the answer most OS designers would
give to using BIOS calls in protected mode is a
resounding *NO*! The standard BIOS software is
all 16-bit real mode code; the work needed to
access it from p-mode (initializing a v86 taks,
jumping to and from p-mode and v86 mode for even
the simplest I/O, etc.) is far more work than
writing your own p-mode drivers. While this has
been a matter of some controversy, it is
generally agreed that using the BIOS in p-mode is
very unwise.
The choice is less clear for a real mode OS.
While using the BIOS can save a great deal of
hassle, and is familiar to the many DOS
programmers already, it has several drawbacks.
BIOS routines are generally considerably slower
than your own code would be; more seriously, BIOS
routines are designed around polling, not
interrupts, and are consequently inherently
inefficient in a multitasking system, and even in
a single-tasking OS use more time and space than
they should as a result. Even DOS rewrote many if
not most of the low-level functions in it's later
incarnations. Writing one's own drivers, while
often a great deal of work, can still be well
worth the effort.
Q: Should I write my own bootstrap?
A: The general concensus is that, while it is a good idea to experiment with writing *a*
bootstrap loader in order to better undertand the
boot process, most OS writers would be far better
served using an existing boot loader like GRUB
for their actual OSes. The boot process is
extremely hairy, and can a suitable one has to
handle a great many different hardware
configurations. Too many OS projects have sank on
those shoals; it is far better to put your effort
into writing your kernel and memory manager than
waste a lot of effort on something that should be
at most a few seconds of your system's running
time.
I'm out of time, but I'll have more soon. Any
comments or corrections?