standalone system:

The second article in the "PORTING UNIX TO THE 386" series discussed the utilities we had to build to test the port on an actual 80386 PC.
By far, the most popular article.

This article, last of the original three done altogether in 1990, on getting the critical pieces functioning independantly that we needed to do the port. Once these we obtained, the kernel was inevitable.

Anticipating problems allowed us to find flaws in our work. We use the standalone system for bootstrap to load test programs that work machine-dependant portions of the kernel.

We stepwise proved out the running environment of program tools, program loading and execution, trap handling, stack, and support of high level language. Our project moved from fragile to substantive.

Originally the test framework to prove kernel parts work in the environment of an protected mode program running on the "raw" machine, this became the bootstrap environment to later load and start the kernel in system operation.

Since we had a program running in an empty PC, we needed primative input with a keyboard driver for polled input. Used by standalone programs to boot and test parts of the kernel.

Output from our standalone programs was done by a primative display driver to allow standalone programs to display results from bootstrap and test programs. We avoided the BIOS entirely.

We didn't just load and debug the kernel; we chose to prove portions first. That way we learned the dependances first, and could try alternatives seperately. Later we used the same means to revise them later.

Booting a kernel didn't require all of this - but by extending support, we had a "mini kernel" like functionality. Dillemma - how much do you let the boostrap/loader actually do? We chose after the kernel was up to have it to the most - but this answer is subject to review.

We initialized the processor with initial descriptor and page tables - one needs to run with the tables before activating memory/interrupt kernel functions.

Here's an oddity we had in the initial port. We first avoided the 386 TSS context switch because it was slow. With the 486 and later, it wasn't so we used it. But we needed at lead one to transit rings.

We coded stub routines to connect trap handlers to descriptor table entry points, wiring the kernel to receive processor traps.

We coded specialized trap handlers for interrupt traps, as these were initimate with the systems interrupt control hardware, not part of the processor.

System calls were handled by a call gate, a 386 peculiar mechanism which allowed for ring crossing into supervisor mode using a special segment descriptor call. We simulated user mode to test prior to running in the kernel.

We coded trap handlers and simulated read and write faults to test out page faults with our processor support code. On a 2MB machine, we knew we'd get 1,000's.

We had put the plan of the first article into action, used the second articles tools to load test programs as the kernel, extending standalone operation. This created a base for the kernel and user environment.

We describe the need and use of a cross-support environment to create 386 code from a non-386 machine, so as to create the initial binarys before our port can generate them.

The tool chest for 386BSD cross support included compiler, assembler, loader, libraries and include files. It did not include an emulation environment.

We started with a cheap lunchbox PC with a 40MB drive, and had to change as we exhausted serial downloads and DOS was squeezed of the drive for space for BSD.

Nothing ever goes right the first time, so a incremental process of bringing up the filesystem, from standalone utilities to system initialization allows us to debug flaws in filesystem creation, often artifacts of its non-native creation.

Understanding the boundary between research and development with BSD, and where a balance between commercial efforts can be struck.