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

Requirements for a DOS PC Utility to boot a 386BSD UNIX kernel.

Why we wrote PC utilities to port UNIX with - the advantage of working from a primitive OS that runs on the absolute machine.

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.

Once the system is debugged and tested, the next step was to load on more code to expand with. So we moved "tar balls" to the swap space with this utility to provide a primative file upload capability.

Ironically, these utilities advanced progress fast enough that once the kernel was operational, the biggest obstacle became booting off of DOS. So the next step was to implement a bootstrap and standalone system so that we could rid ourself of DOS entirely.

Synopsis of what 386BSD was intended to be in the 1989-1990 timeframe.

What should have happened was that Berkeley should have released a basic 386 system binary and source release, and followed it up with a general release.

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.

Choosing how far to go in supporting X86 architecture in order to get a basic BSD UNIX system to be able to bootstrap the futre efforts.

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.

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

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.

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.

Our Symmetric 375 was close but not identical to a 386 - its National 32000 series microprocessor was different. Yet it was a good choice for cross host in a cross development environment.

We describe the origin and orientation of the "Free Software" vs. "Open Software" efforts via respective licenses.

386BSD is a Berkeley system, its authors were from Berkeley, and it is under a Berkeley license.

We build the first instance of the root filesystem - before any operational system is present on the 386 to build one. Part of the bootstrapping cycle of getting up the first running system on a new architecture.

A breakdown of the various uses of the root filesystems, and the considerations for each as we prove out the operation of the system step by step.

Portions of the root allow the kernel to be installed as the fundamental component of the operating system. These standalone programs occupy space within the root filesystem.

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

Where do you get the root filesystem, when you need it to make itself? Answer - you make it on another system, in this case one quite different, and then you break the recursion.

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?

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