article:

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.

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.

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.

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

We used another proven UNIX system - a Symmtric 375, to cross compile 386 code (bootstrap, kernel, shell, utilities) to get the first system running.

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

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.

What is it that makes up a filesystem? This depends very much on what kind of filesystem we are talking about.

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