Berkeley UNIX:

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.

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.

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.

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 started out in 1989 with a derivative virtual memory system from the VAX by way of a 68030. In February/March 1991, it was cutover to a totally different one cut out of CMU's MACH system, and released with Net/2.

Hardware context switch state description and the part where 386BSD context switching intrudes into the machine independent code semantics.

Catching terminal processor faults.

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

To find controllers and devices, we use tables to instruct device drivers where to probe and attach found peripherals and connect them with low-level drivers and high-level kernel subsystems.

How to bootstrap the system from hardware, loading the kernel program, itself a protected mode executable from secondary / nonvolatile / disk storage.

The state of the 386BSD world back in mid-1990 is synopsized here. By the time this appeared, EISA and other "beyond AT" support had been added. CSRG only let other UC institutions have code, although a complete binary and source release was present and tested for 6 months.

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

BSD started before ANSI C, and still seems wedded to it even in 2006! GCC with the "traditional" flag didn't quite work, so we compromised.

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