system call:

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

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.

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

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.

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.

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.

The "u." in more detail, handling kernel stack overflows in 386BSD.

Sometimes you're forced to use processor features - like hardware context switching. Origionally, the earliest versions of 386BSD didn't use the hardware context switch TSS feature - but you still had to have one anyways.

How to call the system's kernel from a process, using existing industry standards accross the X86 platform.

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.

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.

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.

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.

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.