segmentation:

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.

Most popular microprocessors use either segmentation or paging to manage memory address space access. The 386 is rare in that it possesses both. In fact, since segmentation, (see Figure 3(a)), is placed on top of paging (see Figure 3(b)), you are expected to use segmentation in some form any time memory is paged. And, most important, BSD relies on paging.

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.

Catching potentially restartable 386 processor faults with 386BSD.

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

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.