ring:

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.

DOS C program for loading 386BSD kernel from DOS, and executing it, taking over the machine.

After loading the kernel program, we enter protected mode to start up the 386BSD kernel, itself a protected mode program like its own applications.

First thing the kernel does is open its root filesystem - so we need a way to write a filesystem onto the hard disk, adjacent to the DOS filesystem, which is what this utility does.

This, the first article, is the first published mention of 386BSD. By this time, the project had been operational for 18 months, and William Jolitz was at Berkeley working on the Net/2 release.
In this installment, we discussed the beginning of our project and the initial framework that guided our efforts, in particular, the development of the 386BSD specification.

We'd gathered books and equipment to begin the port in 1989. Most critical was the Crawford and Gelsinger book.
We went through many PCs, most of them portables. Compaq sent a DeskPro 386, and SystemPro 386 & 486.

The 386BSD specification was in two parts - one that detailed getting to a operational system that could build itself and basic console applications, and a more extensive community involvement part, called "A Modest Proposal".

We decided to shoot for a system that emphasized novel 386 support code to create a basic BSD environment on the 386. We assumed that by making it freely available, others will extend the work to remaining areas.

Reconciling segmentation to UNIX has never been easy, and with 386BSD its an even greater chore. The issues of supporting X86 segments in a Berkeley UNIX world.

386BSD ignored as much as possible the segmentation hardware of the x86, preferring to use a "flat" address space.

386BSD executed programs with a virtual address similar to a VAX running UNIX. In February 1991, this changed so that the format of the process virtual address space memory usage could be arranged differently.

One surprise with 386BSD was that the 80386 doesn't honor write protection on the user page addresses, requiring a work-around. This was fixed in 80486 and all subsequent X86 processors.

Catching terminal processor faults.

The actual memory referenced on processor, system, and I/O device busses, or physical memory addresses have standard assignments for the kernel to manage for the operating system to function.

Support the processor, and support the ISA bus peripherals are the objectives for the first parts of 386BSD.

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.

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

Our use of cross-tools was simply to bootstrap onto the 386 - not to perfect ongoing development. So, if we found a problem with the tool, we bypassed it with a one time workaround - cross tools didn't need to work for everything.

Our methodology was to prove that we could get a usable, tested executable across onto the native machine to be useful there. As we found and fixed, this methodology sped getting enough good and working native components, such that we could begin native development.

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.

With cross tools we could make utility programs for our nascent system. The next step would be incorporating them into a filesystem so that they could run on the native 386, with the kernel program.

The view of copyright and the GPL as it was back in the early 90's.

With the kernel running, we do a "high level bootstrap" to initialize the operating system, by executing certain programs located in the root filesystem.

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.

Whats different about operating systems like Unix that use a root filesystem, and other systems that don't require a filesystem to be mounted initially to operate?