development:

Our kernel is a UNIX executable file, just like all of its applications. So what does the a.out file, compiled and loaded usiing GCC and utilities look like?

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

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.

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

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

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 had put the plan of the first article into action, used the second articles tools to load test programs as the kernel, extending standalone operation. This created a base for the kernel and user environment.

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.

Our use of cross-tools was simply to bootstrap onto the 386 - not to perfect ongoing development. So, if we found a problem with the tool, we bypassed it with a one time workaround - cross tools didn't need to work for everything.

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.

We started with a cheap lunchbox PC with a 40MB drive, and had to change as we exhausted serial downloads and DOS was squeezed of the drive for space for BSD.

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.

Open standards, open source, and free software are not the same thing - they are very different.

The view of copyright and the GPL as it was back in the early 90's.

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.